[gentoo-user] Debian just voted in systemd for default init system in jessie

[gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

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.

Read it here:

http://vsido.org/index.php?topic=653.45

I'd really like to see a similar discussion/debate by those far more 
knowledgeable than I with respect to systemd vs OpenRC, but the above 
does bring up a lot of salient points.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On Feb 15, 2014 11:02 AM, "Tanstaafl" <tanstaafl@libertytrek.org> wrote:
>
> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2009 bytes --]

On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote:
> On Feb 15, 2014 11:02 AM, "Tanstaafl" <tanstaafl@libertytrek.org> wrote:
> > On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 11:32 AM, Canek Peláez Valdés wrote:
> On Feb 15, 2014 11:02 AM, "Tanstaafl" <tanstaafl@libertytrek.org
> <mailto:tanstaafl@libertytrek.org>> wrote:
>>
>> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@libertytrek.org
> <mailto:tanstaafl@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.
> 
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
> 

The lack of foresight on social and political ramifications is epidemic
to most of the FOSS world, as evidenced by the creeping adoption of
systemd. Things are already depending on things that systemd provides,
and is dividing the ecosystem into "systemd" vs "everything else".
Ambitious projects like systemd are damaging to the rich variety that
should be found in the FOSS ecosystem. systemd in particular encourages
embracing vertical integration and rejection of POSIX and UNIX
principles. Its culture is adversarial to anyone who doubts the Great
Image that Lennart and his employer has. If it were a project that was
humble, without an agenda, and did not undergo evangelism, I'd have no
problems with it because choice is something that I value immensely. But
because it *isn't* humble, *has* an agenda, only reached the adoption it
currently has by *lots* of arguing and pushing, and refuses to coexist
with other init systems, I cannot respect it as a legitimate,
non-aggressive, non-intrusive software project. I consider it a toxic
threat to FOSS and refuse to have it on any system I maintain.

systemd has technical merits (cgroups, socket activation, parellel
execution of daemons, etc), but they fall by the wayside and become
irrelevant to me when it swallows the functionality of multiple projects
that should be separate (see: udev) and tries to be everything to
everyone (splash image, web server, boot time graphs, etc). The social
tactics at work from the systemd team (and verily, other Red Hat
projects like GNOME) are reminiscent of Microsoft through the use of the
"Embrace, Extend, Extinguish" methodology. With their paid developers
and more abundant resources, Red Hat (and arguably other corporations)
can use their developers to push their agendas and, in a sense,
commandeer control of the FOSS world. I will give them no inch on my
systems. I am skeptical of their involvement in the kernel, as well.

It's sad to see Debian giving into peer pressure. I honestly thought
that they would see the agenda miles away and prevent a monoculture. For
people who are technically intelligent, they're seriously lacking any
foresight in their decisions and are completely blind to the social and
political ramifications. Distros will regret depending on such a project
and it will set GNU/Linux development back many years when systemd
becomes a full stack and working without it is made difficult or
impractical (through the use of lock-in tactics). I hope that Gentoo
continues to be a safe haven for choice and the spirit of FOSS. Without
it, I may have to concede and either start building my own distro, or
going to the BSDs.

Just my two cents. Ignore or reply at your discretion.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sat, Feb 15, 2014 at 2:23 PM, Mick <michaelkintzios@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" <tanstaafl@libertytrek.org> wrote:
>> > On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote:
> On Sat, Feb 15, 2014 at 2:23 PM, Mick <michaelkintzios@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" <tanstaafl@libertytrek.org> wrote:
>>>> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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.

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[eroen]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Sat, 15 Feb 2014 14:34:34 -0600, Daniel Campbell <lists@sporkbox.us>
wrote:
> 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.
> 

I'll just put this link to a forum thread on epoch from late last year,
in case any potentially interested party has not seen it yet. It's
available in the gentoo package tree, and from the thread it seems to
have workable integration.

http://forums.gentoo.org/viewtopic-t-975382-highlight-epoch.html


-- 
eroen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sat, Feb 15, 2014 at 2:34 PM, Daniel Campbell <lists@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 <michaelkintzios@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" <tanstaafl@libertytrek.org> wrote:
>>>>> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@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

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Sat, 15 Feb 2014 14:30:10 -0600
Daniel Campbell <lists@sporkbox.us> wrote:

> On 02/15/2014 11:32 AM, Canek Peláez Valdés wrote:
> > On Feb 15, 2014 11:02 AM, "Tanstaafl" <tanstaafl@libertytrek.org
> > <mailto:tanstaafl@libertytrek.org>> wrote:
> >>
> >> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@libertytrek.org
> > <mailto:tanstaafl@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.
> > 
> > Regards.
> > --
> > Canek Peláez Valdés
> > Posgrado en Ciencia e Ingeniería de la Computación
> > Universidad Nacional Autónoma de México
> > 
> 
> The lack of foresight on social and political ramifications is
> epidemic to most of the FOSS world, as evidenced by the creeping
> adoption of systemd. Things are already depending on things that
> systemd provides, and is dividing the ecosystem into "systemd" vs
> "everything else". Ambitious projects like systemd are damaging to
> the rich variety that should be found in the FOSS ecosystem. systemd
> in particular encourages embracing vertical integration and rejection
> of POSIX and UNIX principles. Its culture is adversarial to anyone
> who doubts the Great Image that Lennart and his employer has. If it
> were a project that was humble, without an agenda, and did not
> undergo evangelism, I'd have no problems with it because choice is
> something that I value immensely. But because it *isn't* humble,
> *has* an agenda, only reached the adoption it currently has by *lots*
> of arguing and pushing, and refuses to coexist with other init
> systems, I cannot respect it as a legitimate, non-aggressive,
> non-intrusive software project. I consider it a toxic threat to FOSS
> and refuse to have it on any system I maintain.
> 
> systemd has technical merits (cgroups, socket activation, parellel
> execution of daemons, etc), but they fall by the wayside and become
> irrelevant to me when it swallows the functionality of multiple
> projects that should be separate (see: udev) and tries to be
> everything to everyone (splash image, web server, boot time graphs,
> etc). The social tactics at work from the systemd team (and verily,
> other Red Hat projects like GNOME) are reminiscent of Microsoft
> through the use of the "Embrace, Extend, Extinguish" methodology.
> With their paid developers and more abundant resources, Red Hat (and
> arguably other corporations) can use their developers to push their
> agendas and, in a sense, commandeer control of the FOSS world. I will
> give them no inch on my systems. I am skeptical of their involvement
> in the kernel, as well.
> 
> It's sad to see Debian giving into peer pressure. I honestly thought
> that they would see the agenda miles away and prevent a monoculture.
> For people who are technically intelligent, they're seriously lacking
> any foresight in their decisions and are completely blind to the
> social and political ramifications. Distros will regret depending on
> such a project and it will set GNU/Linux development back many years
> when systemd becomes a full stack and working without it is made
> difficult or impractical (through the use of lock-in tactics). I hope
> that Gentoo continues to be a safe haven for choice and the spirit of
> FOSS. Without it, I may have to concede and either start building my
> own distro, or going to the BSDs.

Thank you for the explanation. I suspected this yet from the beginning
of this discussion and waited for such or similar explanations.

Technically, I so far know a very little on this subject
and only suspect :-) that my Gentoo system uses openrc.

I am quite satisfied with it and afraid of switching Gentoo default to
systemd.

However, I do understand your arguments concerning Ubuntu and Gnome.

This year I put them both into a recycle bin as I very well felt their
"Embrace, Extend, and Extinguish" tactics.

Just my two cents too. :-)

> Just my two cents. Ignore or reply at your discretion.
> 

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[walt]

On 02/15/2014 12:30 PM, Daniel Campbell wrote:
> The social
> tactics at work from the systemd team (and verily, other Red Hat
> projects like GNOME) are reminiscent of Microsoft through the use of the
> "Embrace, Extend, Extinguish" methodology.

I certainly share your hostility towards M$ for suppressing competition.

Red Hat, like M$, is a for-profit corporation, so I share your suspicion
that they want to suppress their competitors (though I don't know who
their competitors are).

But comparing a completely closed-source shop like M$ to any open source
company leaves me feeling uneasy.  I can't find the exact argument to
explain my unease, but I'm hoping someone else will jump in with a more
rational argument.
 

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Alon Bar-Lev]

On Sun, Feb 16, 2014 at 4:09 AM, walt <w41ter@gmail.com> wrote:
>
> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
> > The social
> > tactics at work from the systemd team (and verily, other Red Hat
> > projects like GNOME) are reminiscent of Microsoft through the use of the
> > "Embrace, Extend, Extinguish" methodology.
>
> I certainly share your hostility towards M$ for suppressing competition.
>
> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
> that they want to suppress their competitors (though I don't know who
> their competitors are).
>
> But comparing a completely closed-source shop like M$ to any open source
> company leaves me feeling uneasy.  I can't find the exact argument to
> explain my unease, but I'm hoping someone else will jump in with a more
> rational argument.

Once the vertical will be too high and spaghetti like, there will be
no difference between close source and open source vendor, as nobody
will be able to maintain the vertical without being payed for it. Even
if one believes that he has a great fix/improvement, he won't be able
to get it merged unless he is endorsed or work in specific vendor, as
the roadmap, support matrix and content will be determined by that
"open source" vendor. It will be impossible to fork it either as
forking the entire vertical is out of the question.

Regards,
Alon

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> 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/

I would really, really, REALLY like to see a thorough, civil debate 
involving those far more knowledgeable than I on the pros and cons of 
systemd vs OpenRC...

As it seems to me, the Debian OpenRC page says that the cons are not 
nearly as large as the systemd proponents would have us believe.

https://wiki.debian.org/Debate/initsystem/openrc

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 16/02/2014 17:46, Tanstaafl wrote:
> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> 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/
> 
> I would really, really, REALLY like to see a thorough, civil debate
> involving those far more knowledgeable than I on the pros and cons of
> systemd vs OpenRC...
> 
> As it seems to me, the Debian OpenRC page says that the cons are not
> nearly as large as the systemd proponents would have us believe.
> 
> https://wiki.debian.org/Debate/initsystem/openrc


I don't know much about systemd, I do know openrc.

Thus far, the only real actual benefit I have seen of systemd that is a
real issue that really affects me is consolekit. It's not exactly the
best piece of software out there, comparable to HAL and how it was
replaced by udev. So systemd replaces and fixes consolekit by providing
logind.

As for all the other supposed benefits of systemd - I don't see them in
my world; perhaps they do exist in someone else's worls, I can't really
comment on that. But they don't exist in mine and therefore that makes
systemd's solutions theoretical for me.

Everything I might like in systemd is already implemented in OpenRC so I
have no compelling need to switch. Besides, my computers do not break
when they boot and shutdown, service management works reliably and well,
there are no race conditions on boot that affect me and I still to this
day do not understand why I would need cgroups at all.

Whatever problems Red Hat are trying to solve in the Red Hat space are
problems that do not affect me, so I do not need Red Hat's solution. As
for Gnome, I have yet to see a valid reason why Gnome *must* use
systemd; that is simply not true at all.

Systemd is there, Gnome decided to use it. the Gnome team could just as
easily have decided to not use it, or use bits of it, or whatever. Using
systemd in Gnome was a choice, not something that had to be done due to
a constraint.

So overall, systemd might very well solve a particular vertical problem
(point to them if it does), but I truly do not see how it can be the
OneTrueInitSystem, the One That In The Darkness Binds Us.

My 0.02 millicents


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> 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/
>
>
> I would really, really, REALLY like to see a thorough, civil debate
> involving those far more knowledgeable than I on the pros and cons of
> systemd vs OpenRC...

Well, that's the pickle, isn't it? We have the usual stuff:

• OpenRC wasn't able (until very recently) to properly do parallel
execution of daemons. There will be someone who will say "that isn't
important".

• Then there is the inability of OpenRC to properly stop/monitor
daemons (everybody here had to use "/etc/init.d/daemon zap" at some
point, I suppose). Someone will say that there is experimental cgroups
support for OpenRC... "experimental" being the important word, and
there is also the little matter of that not being integrated into the
official package (AFAIU). Also, with that OpenRC loses the "advantage"
of being portable to FreeBSD and/or Hurd.

• And of course, OpenRC is slow as hell compared to systemd (although
there are reports of being really fast using reentrant busybox... I
never used that way, so I don't know). Which again, someone will say
that "that doesn't matter because I never reboot my machine". Great.

But then we have the whole load of features that systemd provides that
no other init system does (OpenRC included). That is an advantage if
you believe that having an standardized plumbing in all "mainstream"
Linux distributions has technical merit and is a good design. If you
believe so (like I and many others do), then systemd is several orders
of magnitude better than OpenRC. If you don't believe so (like many...
although apparently they are less and less as time goes by), then
systemd is the spawn of the devil and it should be killed with fire.

For General Purpose Linux distributions, systemd is a godsend since it
solves and centralizes a lot of stuff that matters to a lot of people.
It's fast and small (if you remove the optional dependencies), so the
embedded guys like it. It offers (for the first time ever) proper
daemon control and management and O(log n) access logs, so the server
guys like it. And if offers proper session monitoring and seat
control, so the desktop guys like it too.

But all those advantages only will be so, if you agree with having a
tightly integrated plumbing interface directly above the kernel and
below PAM and/or X (soon Wayland) sessions. It gets kind of
philosophical, which is why a lot of people taunts the fuzzy term
"UNIX philosophy" so much when they rave against systemd.

> As it seems to me, the Debian OpenRC page says that the cons are not nearly
> as large as the systemd proponents would have us believe.
>
> https://wiki.debian.org/Debate/initsystem/openrc

It's because they are cons only if you agree with systemd's view of the world.

I do.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Samuli Suominen]

On 16/02/14 18:41, Alan McKinnon wrote:
> On 16/02/2014 17:46, Tanstaafl wrote:
>> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> 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/
>> I would really, really, REALLY like to see a thorough, civil debate
>> involving those far more knowledgeable than I on the pros and cons of
>> systemd vs OpenRC...
>>
>> As it seems to me, the Debian OpenRC page says that the cons are not
>> nearly as large as the systemd proponents would have us believe.
>>
>> https://wiki.debian.org/Debate/initsystem/openrc
>
> I don't know much about systemd, I do know openrc.
>
> Thus far, the only real actual benefit I have seen of systemd that is a
> real issue that really affects me is consolekit. It's not exactly the
> best piece of software out there, comparable to HAL and how it was
> replaced by udev. So systemd replaces and fixes consolekit by providing
> logind.

ConsoleKit works just fine for the features it advertises to have, where
as HAL never did,
so I really don't know what you are referring to?

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 5372 bytes --]

On Sunday 16 Feb 2014 16:50:26 Canek Peláez Valdés wrote:
> On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl <tanstaafl@libertytrek.org> 
wrote:
> > On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> >> 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/
> > 
> > I would really, really, REALLY like to see a thorough, civil debate
> > involving those far more knowledgeable than I on the pros and cons of
> > systemd vs OpenRC...
> 
> Well, that's the pickle, isn't it? We have the usual stuff:
> 
> • OpenRC wasn't able (until very recently) to properly do parallel
> execution of daemons. There will be someone who will say "that isn't
> important".
> 
> • Then there is the inability of OpenRC to properly stop/monitor
> daemons (everybody here had to use "/etc/init.d/daemon zap" at some
> point, I suppose). Someone will say that there is experimental cgroups
> support for OpenRC... "experimental" being the important word, and
> there is also the little matter of that not being integrated into the
> official package (AFAIU). Also, with that OpenRC loses the "advantage"
> of being portable to FreeBSD and/or Hurd.
> 
> • And of course, OpenRC is slow as hell compared to systemd (although
> there are reports of being really fast using reentrant busybox... I
> never used that way, so I don't know). Which again, someone will say
> that "that doesn't matter because I never reboot my machine". Great.
> 
> But then we have the whole load of features that systemd provides that
> no other init system does (OpenRC included). That is an advantage if
> you believe that having an standardized plumbing in all "mainstream"
> Linux distributions has technical merit and is a good design. If you
> believe so (like I and many others do), then systemd is several orders
> of magnitude better than OpenRC. If you don't believe so (like many...
> although apparently they are less and less as time goes by), then
> systemd is the spawn of the devil and it should be killed with fire.
> 
> For General Purpose Linux distributions, systemd is a godsend since it
> solves and centralizes a lot of stuff that matters to a lot of people.
> It's fast and small (if you remove the optional dependencies), so the
> embedded guys like it. It offers (for the first time ever) proper
> daemon control and management and O(log n) access logs, so the server
> guys like it. And if offers proper session monitoring and seat
> control, so the desktop guys like it too.
> 
> But all those advantages only will be so, if you agree with having a
> tightly integrated plumbing interface directly above the kernel and
> below PAM and/or X (soon Wayland) sessions. It gets kind of
> philosophical, which is why a lot of people taunts the fuzzy term
> "UNIX philosophy" so much when they rave against systemd.
> 
> > As it seems to me, the Debian OpenRC page says that the cons are not
> > nearly as large as the systemd proponents would have us believe.
> > 
> > https://wiki.debian.org/Debate/initsystem/openrc
> 
> It's because they are cons only if you agree with systemd's view of the
> world.
> 
> I do.

I think what people primarily object to is not the parts that systemd does 
well or does better than other init process start up systems.  The main 
objection from what I understand is the removal of choice that systemd 
developers have forced upon users, by making certain architectural decisions.  
These are decisions which may look optimal for RHL, but appear to be less so 
for the rest of the *nix ecosystem given the objections to systemd across the 
populace.

For some Gentoo users in particular, removing the choice of running /usr on a 
separate partition (without *forcing* the use of initramfs) created the first 
pain point, or wakeup call.  Many complaints were posted on this M/L, 
centering on this removal of choice.  Unlike binary distros Gentoo is all 
about choice, so the complaints were perhaps louder than elsewhere.

People speaking of *nix design philosophy are not necessarily having a rant, 
but can be legitimately concerned that architectural decisions to hardwire 
systemd into Linux will remove choice from its wider user base.  I am 
similarly concerned that a monoculture has less success of survival.  The fact 
that Debian decided to embrace the systemd option will no doubt have an impact 
on what Gentoo follows.

I am not educated in init start up systems to know why other options were not 
considered as part of the Debian debate.  Is it that runit, or epoch or what-
else are not even close in terms of functionality, versatility and choice?  
Framing a question can narrow the answers.

I hope that whatever the Gentoo decision may be one day, it will not 
irreversibly remove choice from us Gentoo-ers.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Volker Armin Hemmann]

Am 15.02.2014 16:16, schrieb Tanstaafl:
> 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.
>
> Read it here:
>
> http://vsido.org/index.php?topic=653.45
>
> I'd really like to see a similar discussion/debate by those far more
> knowledgeable than I with respect to systemd vs OpenRC, but the above
> does bring up a lot of salient points.
>
>
http://ewontfix.com/14/

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Volker Armin Hemmann]

Am 16.02.2014 17:50, schrieb Canek Peláez Valdés:
> On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> 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/
>>
>> I would really, really, REALLY like to see a thorough, civil debate
>> involving those far more knowledgeable than I on the pros and cons of
>> systemd vs OpenRC...
> Well, that's the pickle, isn't it? We have the usual stuff:
>
> • OpenRC wasn't able (until very recently) to properly do parallel
> execution of daemons. There will be someone who will say "that isn't
> important".
>
> • Then there is the inability of OpenRC to properly stop/monitor
> daemons (everybody here had to use "/etc/init.d/daemon zap" at some
> point, I suppose). Someone will say that there is experimental cgroups
> support for OpenRC... "experimental" being the important word, and
> there is also the little matter of that not being integrated into the
> official package (AFAIU). Also, with that OpenRC loses the "advantage"
> of being portable to FreeBSD and/or Hurd.
>
> • And of course, OpenRC is slow as hell compared to systemd (although
> there are reports of being really fast using reentrant busybox... I
> never used that way, so I don't know). Which again, someone will say
> that "that doesn't matter because I never reboot my machine". Great.
>
> But then we have the whole load of features that systemd provides that
> no other init system does (OpenRC included). That is an advantage if
> you believe that having an standardized plumbing in all "mainstream"
> Linux distributions has technical merit and is a good design. 


or it is an idiotic decision. Because features means complexity.
Complexity means bugs.

And you don't want complexity in PID1 or init. Let those 'features' be
handled by their own specialists.

You know, the unix way. Do one thing, do it well. Use text to
communicate. That stuff. That makes things easy. And flexible. And
replaceable.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 16.02.2014 20:50, Canek Peláez Valdés wrote:
[ ... ]
> It's because they are cons only if you agree with systemd's view of the world.
>
> I do.

Isn't there too many "if you believe" and "if you agree"? A church of 
systemd? ;)

I wonder why all systemd's fancy stuff hasn't yet been integrated into 
any existing init system, because of theoretical impossibility or just 
practical uselessness?

Actually why not do the daemon management, logging, cron etc in the 
Linux kernel itself? It's obvious, and we even have a perfect example of 
kernel-integrated graphics around -- `guess the OS name`. It also has 
much in common with systemd; "Believe us it's the best OS", "Believe us 
it provides loads of features", "Agree with having binary logs" etc.

A competent approach for choosing software for a task is answering the 
questions:
1. Is the software standards-compliant?
2. Does the software have an alternative compatible implementation?
3. Is the software developed to achieve a certain, concrete goal?
4. Does the software achieve the goal?
5. Does the software achieve the goal "gracefully"?
6. Does the software have a clear perspective and view what it will be like?
7. Is the software developed and maintained by a reliable company or group?

AFAICT, with systemd there's by far one "yes". The other answers are 
dubious if just plain "no".

I'd personally share Alan McKinnon's POV: there's no real reason to 
switch to systemd since the present init systems serve pretty well and 
the benefit, if any, isn't worth the adaptation threshold.

But why then is Linux drifting to systemd? The answer is simple: money. 
Time is money. You have to support two init systems -> twice the time, 
twice the money. Sooner or later, a sum of money will outweigh the 
users' opinion. To be a realist, one has to admit that in near future 
90% of new distro versions will be systemd-based. Unless some green soxx 
emerge and take over Red Hat...

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2662 bytes --]

On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote:
> On 16.02.2014 20:50, Canek Peláez Valdés wrote:
> [ ... ]
> 
> > It's because they are cons only if you agree with systemd's view of the
> > world.
> > 
> > I do.
> 
> Isn't there too many "if you believe" and "if you agree"? A church of
> systemd? ;)
> 
> I wonder why all systemd's fancy stuff hasn't yet been integrated into
> any existing init system, because of theoretical impossibility or just
> practical uselessness?
> 
> Actually why not do the daemon management, logging, cron etc in the
> Linux kernel itself? It's obvious, and we even have a perfect example of
> kernel-integrated graphics around -- `guess the OS name`. It also has
> much in common with systemd; "Believe us it's the best OS", "Believe us
> it provides loads of features", "Agree with having binary logs" etc.
> 
> A competent approach for choosing software for a task is answering the
> questions:
> 1. Is the software standards-compliant?
> 2. Does the software have an alternative compatible implementation?
> 3. Is the software developed to achieve a certain, concrete goal?
> 4. Does the software achieve the goal?
> 5. Does the software achieve the goal "gracefully"?
> 6. Does the software have a clear perspective and view what it will be
> like? 7. Is the software developed and maintained by a reliable company or
> group?
> 
> AFAICT, with systemd there's by far one "yes". The other answers are
> dubious if just plain "no".
> 
> I'd personally share Alan McKinnon's POV: there's no real reason to
> switch to systemd since the present init systems serve pretty well and
> the benefit, if any, isn't worth the adaptation threshold.
> 
> But why then is Linux drifting to systemd? The answer is simple: money.
> Time is money. You have to support two init systems -> twice the time,
> twice the money. Sooner or later, a sum of money will outweigh the
> users' opinion. To be a realist, one has to admit that in near future
> 90% of new distro versions will be systemd-based. Unless some green soxx
> emerge and take over Red Hat...


You may have lost it in the link that Volker posted (thanks Volker), but this 
comment from HaakonKL probably sums it up:

"... I will give Upstart this though: Should something better come along, you 
could replace upstart. I guess this holds true for OpenRC as well.

You can't say that about systemd."

Can you surgically remove systemd in the future without reverse engineering 
half of what the LSB would look at the time, or will its developers ensure 
that this is a one time choice only?
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 16.02.2014 23:26, Mick wrote:
> On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote:
>> [ ... ]
>> But why then is Linux drifting to systemd? The answer is simple: money.
>> Time is money. You have to support two init systems -> twice the time,
>> twice the money. Sooner or later, a sum of money will outweigh the
>> users' opinion. To be a realist, one has to admit that in near future
>> 90% of new distro versions will be systemd-based. Unless some green soxx
>> emerge and take over Red Hat...
>
>
> You may have lost it in the link that Volker posted (thanks Volker), but this
> comment from HaakonKL probably sums it up:

Sorry, by the time Volker posted his message, I was already writing mine.

> "... I will give Upstart this though: Should something better come along, you
> could replace upstart. I guess this holds true for OpenRC as well.
>
> You can't say that about systemd."
>
> Can you surgically remove systemd in the future without reverse engineering
> half of what the LSB would look at the time, or will its developers ensure
> that this is a one time choice only?

Do you disagree with my statement that "in near future 90% of new distro 
versions will be systemd-based"? Or with some other statement of mine? 
If the former, then I intentionally put it down to money with no regard 
to technical performance because money is usually what ultimately 
matters for maintainers.

 From a Software User's POV, as I said, I agree that systemd is a load 
of bul^W things whose significance is at the least overrated. From a 
technical POV, I bet, most systemd's cookies could be implemented within 
any other init system as well, if required.

But in the Real World, software users either develop theirs own if they 
have the resources, or get what they are given by those who have. So my 
whole message was about -- whether OpenRC/upstart/anything guys have 
resources to "show'em" or eventually fall to systemd.

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 12:31 PM, Mick <michaelkintzios@gmail.com> wrote:
[ snip ]
> well or does better than other init process start up systems.  The main
> objection from what I understand is the removal of choice that systemd
> developers have forced upon users, by making certain architectural decisions.
> These are decisions which may look optimal for RHL, but appear to be less so
> for the rest of the *nix ecosystem given the objections to systemd across the
> populace.

I'm sorry, but what is being forced on whom? Everything is Free
Software, anyone can choose to use SysV, OpenRC, or Upstart if they so
do desire. *Someone* needs to support that software, though.

In the case of SysV and OpenRC, I don't think they will have problem;
they will probably live forever. Upstart, on the other hand, could be
easily be dead in a couple of months: its original author actually
endrses systemd [1].

> For some Gentoo users in particular, removing the choice of running /usr on a
> separate partition (without *forcing* the use of initramfs) created the first
> pain point, or wakeup call.

That has nothing to do with systemd, nor udev; they actually work with
/usr in another partition, they just print a warning. And presently
OpenRC also requires an initramfs if you have /usr on another
partition.

Again, that is not *forcing* anything on anyone. It's just maintainers
(Gentoo devs in the case of Gentoo's council decision) limiting the
total number of supported combinations, because the number of
developers/maintainers we have is finite.

Again, if anyone wants *every*, possible combination, *someone* has to
write the software to support them.

>  Many complaints were posted on this M/L,
> centering on this removal of choice.  Unlike binary distros Gentoo is all
> about choice, so the complaints were perhaps louder than elsewhere.

Gentoo and Linux in general are about choice, as long as someone is
willing and able to write the software to support that choice.

> People speaking of *nix design philosophy are not necessarily having a rant,
> but can be legitimately concerned that architectural decisions to hardwire
> systemd into Linux will remove choice from its wider user base.

*Any* choice will be *always* available as long as someone willing and
able to write the software to support that choice.

> I am similarly concerned that a monoculture has less success of survival.

I think that's a legitimate concern, but it's again kind of
philosophical; all the software it's out there: systemd, Upstart,
OpenRC, SysV, the kernel (including all the versions from the last 22
years),  GNOME, KDE, etc., and it's libre.

If systemd dies, we will replace it with something cooler. I'm willing
to bet the functioning of all my machines to that (as I'm currently
doing).

> The fact
> that Debian decided to embrace the systemd option will no doubt have an impact
> on what Gentoo follows.

For sure.

> I am not educated in init start up systems to know why other options were not
> considered as part of the Debian debate.  Is it that runit, or epoch or what-
> else are not even close in terms of functionality, versatility and choice?
> Framing a question can narrow the answers.

I don't know those init systems enough to give you an answer. What I
do know if that none of them has the momentum of systemd, or as many
developers (and their undeniable talent), as systemd.

But who knows, if someone willing and able keeps punching at it (with
code, not rants), maybe from there it will come the next big thing.

> I hope that whatever the Gentoo decision may be one day, it will not
> irreversibly remove choice from us Gentoo-ers.

The only way a choice will be always available, is that someone is
willing and able to write the software to support it.

It's really that simple.

Regards.

[1] https://plus.google.com/u/0/+ScottJamesRemnant/posts/4eHMc2tvp7C
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
[ snip ]
> or it is an idiotic decision. Because features means complexity.

Yeah, like the kernel.

> Complexity means bugs.

Bugs get reported, bugs get fixes. Life goes on.

> And you don't want complexity in PID1 or init. Let those 'features' be
> handled by their own specialists.

Almost all the features of systemd live outside of PID 1.

> You know, the unix way. Do one thing, do it well.

This is from my desktop machine:

/usr/lib/systemd/systemd-reply-password
/usr/lib/systemd/ntp-units.d
/usr/lib/systemd/systemd-coredump
/usr/lib/systemd/systemd-hostnamed
/usr/lib/systemd/systemd-binfmt
/usr/lib/systemd/systemd-localed
/usr/lib/systemd/systemd-machined
/usr/lib/systemd/systemd-sleep
/usr/lib/systemd/system-generators
/usr/lib/systemd/system-generators/systemd-system-update-generator
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator
/usr/lib/systemd/system-generators/systemd-efi-boot-generator
/usr/lib/systemd/system-generators/systemd-fstab-generator
/usr/lib/systemd/system-generators/systemd-getty-generator
/usr/lib/systemd/system-generators/gentoo-local-generator
/usr/lib/systemd/systemd-fsck
/usr/lib/systemd/systemd-bootchart
/usr/lib/systemd/systemd-shutdown
/usr/lib/systemd/systemd-random-seed
/usr/lib/systemd/system-sleep
/usr/lib/systemd/systemd-remount-fs
/usr/lib/systemd/user-generators
/usr/lib/systemd/systemd-sysctl
/usr/lib/systemd/systemd-timedated
/usr/lib/systemd/catalog
/usr/lib/systemd/system-shutdown
/usr/lib/systemd/systemd-udevd
/usr/lib/systemd/systemd-multi-seat-x
/usr/lib/systemd/systemd-cgroups-agent
/usr/lib/systemd/systemd-user-sessions
/usr/lib/systemd/systemd-journal-gatewayd
/usr/lib/systemd/systemd-quotacheck
/usr/lib/systemd/systemd-shutdownd
/usr/lib/systemd/systemd-modules-load
/usr/lib/systemd/systemd-backlight
/usr/lib/systemd/systemd-ac-power
/usr/lib/systemd/systemd-initctl
/usr/lib/systemd/systemd-readahead
/usr/lib/systemd/systemd-journald
/usr/lib/systemd/systemd-activate
/usr/lib/systemd/systemd
/usr/lib/systemd/systemd-update-utmp
/usr/lib/systemd/systemd-vconsole-setup
/usr/lib/systemd/systemd-logind

All of them are different tools providing one capability to systemd as
a whole. So systemd is a collection of tools, where each one does one
thing, and it does it well.

By your definition, systemd perfectly follows "the unix way".

> Use text to communicate.

systemd can comunicate basically everything via text:

centurion ~ # systemctl show sshd.service | head
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service
systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
LoadState=loaded

For performance reasons, some things are passed or stored as data. Bu
everything works with text also. So, again, it passes your definition.

> That stuff. That makes things easy. And flexible. And replaceable.

Easy to whom? And systemd is more flexible that a lot of init systems,
in my opinion including OpenRC.

All the configuration and APIs are documented, public and open source.
Everything is replaceable if there is someone willing and able to
write a replacement.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
[ snip ]
> Isn't there too many "if you believe" and "if you agree"? A church of
> systemd? ;)

As I said to Tanstaafl, it gets kind of philosophical.

Technically, systemd is the obvious superior choice, and that's why
the TC voted for it in Debian (read the discussion).

> I wonder why all systemd's fancy stuff hasn't yet been integrated into any
> existing init system, because of theoretical impossibility or just practical
> uselessness?

If it's "practically useless", why so many distributions keep choosing
it? Why GNOME started using it?

> Actually why not do the daemon management, logging, cron etc in the Linux
> kernel itself? It's obvious, and we even have a perfect example of
> kernel-integrated graphics around -- `guess the OS name`. It also has much
> in common with systemd; "Believe us it's the best OS", "Believe us it
> provides loads of features", "Agree with having binary logs" etc.

All the software is libre; with only that any comparison to Microsoft
becomes moot.

> A competent approach for choosing software for a task is answering the
> questions:
> 1. Is the software standards-compliant?
> 2. Does the software have an alternative compatible implementation?
> 3. Is the software developed to achieve a certain, concrete goal?
> 4. Does the software achieve the goal?
> 5. Does the software achieve the goal "gracefully"?
> 6. Does the software have a clear perspective and view what it will be like?
> 7. Is the software developed and maintained by a reliable company or group?

That's *your* approach. It's certainly not my approach: I don't care
if Emacs is "standards-compliant" (whatever that means for a text
editor); I don't care if Inkscape has an alternative compatible
implementation; and for the rest of your questions, my answer would be
yes.

> AFAICT, with systemd there's by far one "yes". The other answers are dubious
> if just plain "no".

From your point of view.

> I'd personally share Alan McKinnon's POV: there's no real reason to switch
> to systemd since the present init systems serve pretty well and the benefit,
> if any, isn't worth the adaptation threshold.

That's fine; you don't have to use systemd. But if (as an extreme and
unlikely example), Gentoo decided to switch exclusively to systemd,
then either someone willing and able would need to come out ant start
maintaining the alternatives, or then you should do it.

That's how free software works.

> But why then is Linux drifting to systemd? The answer is simple: money. Time
> is money. You have to support two init systems -> twice the time, twice the
> money. Sooner or later, a sum of money will outweigh the users' opinion. To
> be a realist, one has to admit that in near future 90% of new distro
> versions will be systemd-based. Unless some green soxx emerge and take over
> Red Hat...

I don't think neither time nor money had to do with Debian's (nor
Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision.

It's just technically superior. But's that's just my opinion, and what
I believe ;)

So, amen? :D

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 1:26 PM, Mick <michaelkintzios@gmail.com> wrote:
[snip]
> You may have lost it in the link that Volker posted (thanks Volker), but this
> comment from HaakonKL probably sums it up:
>
> "... I will give Upstart this though: Should something better come along, you
> could replace upstart. I guess this holds true for OpenRC as well.
>
> You can't say that about systemd."

I had read that blog entry before. Is full of errors, like believing
that everything that systemd does is inside PID 1.

There is actually little code inside PID 1; most of systemd
functionality comes from separated binaries. You know, do one thing,
do it right?

From [1]:

"If you build systemd with all configuration options enabled you will
build 69 individual binaries. These binaries all serve different
tasks, and are neatly separated for a number of reasons."

> Can you surgically remove systemd in the future without reverse engineering
> half of what the LSB would look at the time, or will its developers ensure
> that this is a one time choice only?

You guys talk about software like if it was a big bad black magical
box with inexplicable powers.

If someone is willing and able, *everything* can be "surgically
remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
and ESD. KDE got rid of aRts (and who knows what more).

You can get rid of *everything*, if so you desire. But *someone* needs
to write/patch the code.

Regards.

[1] http://0pointer.de/blog/projects/the-biggest-myths.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Volker Armin Hemmann]

Am 16.02.2014 21:27, schrieb Canek Peláez Valdés:
> On Sun, Feb 16, 2014 at 1:26 PM, Mick <michaelkintzios@gmail.com> wrote:
> [snip]
>> You may have lost it in the link that Volker posted (thanks Volker), but this
>> comment from HaakonKL probably sums it up:
>>
>> "... I will give Upstart this though: Should something better come along, you
>> could replace upstart. I guess this holds true for OpenRC as well.
>>
>> You can't say that about systemd."
> I had read that blog entry before. Is full of errors, like believing
> that everything that systemd does is inside PID 1.
>
> There is actually little code inside PID 1; most of systemd
> functionality comes from separated binaries. You know, do one thing,
> do it right?
>
> >From [1]:
>
> "If you build systemd with all configuration options enabled you will
> build 69 individual binaries. These binaries all serve different
> tasks, and are neatly separated for a number of reasons."

and all are linked (not compile&link) in such a manner that you can't
just pick and choose. Oh no, you get the full treatment if you like it
or not.

>> Can you surgically remove systemd in the future without reverse engineering
>> half of what the LSB would look at the time, or will its developers ensure
>> that this is a one time choice only?
> You guys talk about software like if it was a big bad black magical
> box with inexplicable powers.
>
> If someone is willing and able, *everything* can be "surgically
> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
> and ESD. KDE got rid of aRts (and who knows what more).

yeah, as soon as everybody had worked out devfs it got scrapped. As soon
as hal was usable, it was replaced with something new, that never
stopped changing since then. And then came pulseaudio. The solution to a
problem that does not exist. And because of pulseaudio, all the things
that led. to systemd happened.

>
> You can get rid of *everything*, if so you desire. But *someone* needs
> to write/patch the code.
>
> Regards.
>
> [1] http://0pointer.de/blog/projects/the-biggest-myths.html

I am not trusting the people who lied about udev.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Volker Armin Hemmann]

Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
> [ snip ]
>> or it is an idiotic decision. Because features means complexity.
> Yeah, like the kernel.
>
>> Complexity means bugs.
> Bugs get reported, bugs get fixes. Life goes on.
>
>> And you don't want complexity in PID1 or init. Let those 'features' be
>> handled by their own specialists.
> Almost all the features of systemd live outside of PID 1.
>
>> You know, the unix way. Do one thing, do it well.
> This is from my desktop machine:
>
> /usr/lib/systemd/systemd-reply-password
> /usr/lib/systemd/ntp-units.d
> /usr/lib/systemd/systemd-coredump
> /usr/lib/systemd/systemd-hostnamed
> /usr/lib/systemd/systemd-binfmt
> /usr/lib/systemd/systemd-localed
> /usr/lib/systemd/systemd-machined
> /usr/lib/systemd/systemd-sleep
> /usr/lib/systemd/system-generators
> /usr/lib/systemd/system-generators/systemd-system-update-generator
> /usr/lib/systemd/system-generators/systemd-gpt-auto-generator
> /usr/lib/systemd/system-generators/systemd-efi-boot-generator
> /usr/lib/systemd/system-generators/systemd-fstab-generator
> /usr/lib/systemd/system-generators/systemd-getty-generator
> /usr/lib/systemd/system-generators/gentoo-local-generator
> /usr/lib/systemd/systemd-fsck
> /usr/lib/systemd/systemd-bootchart
> /usr/lib/systemd/systemd-shutdown
> /usr/lib/systemd/systemd-random-seed
> /usr/lib/systemd/system-sleep
> /usr/lib/systemd/systemd-remount-fs
> /usr/lib/systemd/user-generators
> /usr/lib/systemd/systemd-sysctl
> /usr/lib/systemd/systemd-timedated
> /usr/lib/systemd/catalog
> /usr/lib/systemd/system-shutdown
> /usr/lib/systemd/systemd-udevd
> /usr/lib/systemd/systemd-multi-seat-x
> /usr/lib/systemd/systemd-cgroups-agent
> /usr/lib/systemd/systemd-user-sessions
> /usr/lib/systemd/systemd-journal-gatewayd
> /usr/lib/systemd/systemd-quotacheck
> /usr/lib/systemd/systemd-shutdownd
> /usr/lib/systemd/systemd-modules-load
> /usr/lib/systemd/systemd-backlight
> /usr/lib/systemd/systemd-ac-power
> /usr/lib/systemd/systemd-initctl
> /usr/lib/systemd/systemd-readahead
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-activate
> /usr/lib/systemd/systemd
> /usr/lib/systemd/systemd-update-utmp
> /usr/lib/systemd/systemd-vconsole-setup
> /usr/lib/systemd/systemd-logind
>
> All of them are different tools providing one capability to systemd as
> a whole. So systemd is a collection of tools, where each one does one
> thing, and it does it well.
>
> By your definition, systemd perfectly follows "the unix way".
>

no, it isn't.

How are those binaries talk to each other?

Besides - why is garbage essential for booting in /usr?

Looks broken. Broken by design. The worst form of broken.

>> Use text to communicate.
> systemd can comunicate basically everything via text:
>
> centurion ~ # systemctl show sshd.service | head
> Id=sshd.service
> Names=sshd.service
> Requires=basic.target
> Wants=system.slice
> WantedBy=multi-user.target
> Conflicts=shutdown.target
> Before=shutdown.target multi-user.target
> After=syslog.target network.target auditd.service
> systemd-journald.socket basic.target system.slice
> Description=OpenSSH server daemon
> LoadState=loaded
>
> For performance reasons, some things are passed or stored as data. Bu
> everything works with text also. So, again, it passes your definition.
>

oh? I can pipe that output into cat or any any daemon I like? Doesn't
look like so.

>> That stuff. That makes things easy. And flexible. And replaceable.
> Easy to whom? And systemd is more flexible that a lot of init systems,
> in my opinion including OpenRC.

oh really? because everything is done by the magical Pöttering?
>
> All the configuration and APIs are documented, public and open source.
> Everything is replaceable if there is someone willing and able to
> write a replacement.

and that has been debunked by others.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Volker Armin Hemmann]

Am 16.02.2014 21:19, schrieb Canek Peláez Valdés:
> Why GNOME started using it?
because of redhat.

Seriously, you had to ask that?

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
>> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
>> <volkerarmin@googlemail.com> wrote:
>> [ snip ]
>>> or it is an idiotic decision. Because features means complexity.
>> Yeah, like the kernel.
>>
>>> Complexity means bugs.
>> Bugs get reported, bugs get fixes. Life goes on.

You didn't answered this, did you?

>>> And you don't want complexity in PID1 or init. Let those 'features' be
>>> handled by their own specialists.
>> Almost all the features of systemd live outside of PID 1.
>>
>>> You know, the unix way. Do one thing, do it well.
>> This is from my desktop machine:
>>
>> /usr/lib/systemd/systemd-reply-password
>> /usr/lib/systemd/ntp-units.d
>> /usr/lib/systemd/systemd-coredump
>> /usr/lib/systemd/systemd-hostnamed
>> /usr/lib/systemd/systemd-binfmt
>> /usr/lib/systemd/systemd-localed
>> /usr/lib/systemd/systemd-machined
>> /usr/lib/systemd/systemd-sleep
>> /usr/lib/systemd/system-generators
>> /usr/lib/systemd/system-generators/systemd-system-update-generator
>> /usr/lib/systemd/system-generators/systemd-gpt-auto-generator
>> /usr/lib/systemd/system-generators/systemd-efi-boot-generator
>> /usr/lib/systemd/system-generators/systemd-fstab-generator
>> /usr/lib/systemd/system-generators/systemd-getty-generator
>> /usr/lib/systemd/system-generators/gentoo-local-generator
>> /usr/lib/systemd/systemd-fsck
>> /usr/lib/systemd/systemd-bootchart
>> /usr/lib/systemd/systemd-shutdown
>> /usr/lib/systemd/systemd-random-seed
>> /usr/lib/systemd/system-sleep
>> /usr/lib/systemd/systemd-remount-fs
>> /usr/lib/systemd/user-generators
>> /usr/lib/systemd/systemd-sysctl
>> /usr/lib/systemd/systemd-timedated
>> /usr/lib/systemd/catalog
>> /usr/lib/systemd/system-shutdown
>> /usr/lib/systemd/systemd-udevd
>> /usr/lib/systemd/systemd-multi-seat-x
>> /usr/lib/systemd/systemd-cgroups-agent
>> /usr/lib/systemd/systemd-user-sessions
>> /usr/lib/systemd/systemd-journal-gatewayd
>> /usr/lib/systemd/systemd-quotacheck
>> /usr/lib/systemd/systemd-shutdownd
>> /usr/lib/systemd/systemd-modules-load
>> /usr/lib/systemd/systemd-backlight
>> /usr/lib/systemd/systemd-ac-power
>> /usr/lib/systemd/systemd-initctl
>> /usr/lib/systemd/systemd-readahead
>> /usr/lib/systemd/systemd-journald
>> /usr/lib/systemd/systemd-activate
>> /usr/lib/systemd/systemd
>> /usr/lib/systemd/systemd-update-utmp
>> /usr/lib/systemd/systemd-vconsole-setup
>> /usr/lib/systemd/systemd-logind
>>
>> All of them are different tools providing one capability to systemd as
>> a whole. So systemd is a collection of tools, where each one does one
>> thing, and it does it well.
>>
>> By your definition, systemd perfectly follows "the unix way".
>>
>
> no, it isn't.
>
> How are those binaries talk to each other?

dbus, which is about to be integrated into the kernel with kdbus.

> Besides - why is garbage essential for booting in /usr?

Is not. Most of it is optional, in a server I have there are much less binaries.

> Looks broken. Broken by design. The worst form of broken.

By your opinion, not others.

>>> Use text to communicate.
>> systemd can comunicate basically everything via text:
>>
>> centurion ~ # systemctl show sshd.service | head
>> Id=sshd.service
>> Names=sshd.service
>> Requires=basic.target
>> Wants=system.slice
>> WantedBy=multi-user.target
>> Conflicts=shutdown.target
>> Before=shutdown.target multi-user.target
>> After=syslog.target network.target auditd.service
>> systemd-journald.socket basic.target system.slice
>> Description=OpenSSH server daemon
>> LoadState=loaded
>>
>> For performance reasons, some things are passed or stored as data. Bu
>> everything works with text also. So, again, it passes your definition.
>>
>
> oh? I can pipe that output into cat or any any daemon I like? Doesn't
> look like so.

But it does, you can "cat" with journalctl; it's one of its output options:

       -o, --output=
           cat
               generates a very terse output only showing the actual
message of each journal entry with no meta data, not even a timestamp.

>>> That stuff. That makes things easy. And flexible. And replaceable.
>> Easy to whom? And systemd is more flexible that a lot of init systems,
>> in my opinion including OpenRC.
>
> oh really? because everything is done by the magical Pöttering?

OK, sorry, I thought you wanted to have a civil, serious, technical
conversation.

I'm done with you in this thread.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 16/02/2014 20:11, Samuli Suominen wrote:
> 
> On 16/02/14 18:41, Alan McKinnon wrote:
>> On 16/02/2014 17:46, Tanstaafl wrote:
>>> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> 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/
>>> I would really, really, REALLY like to see a thorough, civil debate
>>> involving those far more knowledgeable than I on the pros and cons of
>>> systemd vs OpenRC...
>>>
>>> As it seems to me, the Debian OpenRC page says that the cons are not
>>> nearly as large as the systemd proponents would have us believe.
>>>
>>> https://wiki.debian.org/Debate/initsystem/openrc
>>
>> I don't know much about systemd, I do know openrc.
>>
>> Thus far, the only real actual benefit I have seen of systemd that is a
>> real issue that really affects me is consolekit. It's not exactly the
>> best piece of software out there, comparable to HAL and how it was
>> replaced by udev. So systemd replaces and fixes consolekit by providing
>> logind.
> 
> ConsoleKit works just fine for the features it advertises to have, where
> as HAL never did,
> so I really don't know what you are referring to?


It's a poor design. It's also unmaintained currently.

But I don't want to debate consolekit, it's OT for this thread. It runs
on my machines currently because ebuilds pulled it in. It seems to do
what it should, so for the moment I'm happy to leave it in place. But I
don't regard it as a good design, it's one of those things I list in the
risk register in my head and keep an eye on as I consider it brittle.

I only brought it up as an example, an illustration of my position. If
you feel it's a lousy analogy then so be it, but I'd rather not detract
from the topic of the thread, which is systemd.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Samuli Suominen]

On 16/02/14 23:28, Alan McKinnon wrote:
> On 16/02/2014 20:11, Samuli Suominen wrote:
>> On 16/02/14 18:41, Alan McKinnon wrote:
>>> On 16/02/2014 17:46, Tanstaafl wrote:
>>>> On 2014-02-15 3:32 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>> 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/
>>>> I would really, really, REALLY like to see a thorough, civil debate
>>>> involving those far more knowledgeable than I on the pros and cons of
>>>> systemd vs OpenRC...
>>>>
>>>> As it seems to me, the Debian OpenRC page says that the cons are not
>>>> nearly as large as the systemd proponents would have us believe.
>>>>
>>>> https://wiki.debian.org/Debate/initsystem/openrc
>>> I don't know much about systemd, I do know openrc.
>>>
>>> Thus far, the only real actual benefit I have seen of systemd that is a
>>> real issue that really affects me is consolekit. It's not exactly the
>>> best piece of software out there, comparable to HAL and how it was
>>> replaced by udev. So systemd replaces and fixes consolekit by providing
>>> logind.
>> ConsoleKit works just fine for the features it advertises to have, where
>> as HAL never did,
>> so I really don't know what you are referring to?
>
> It's a poor design. It's also unmaintained currently.

How long has it been since Debian decided to go with systemd? Like, three?
So, up until three days ago I would have disagreed since despite original
upstream ditching ConsoleKit, it was still being maintained by Debian and
Gentoo maintainers (me) and last release, 0.4.6, was in fact a result of
that.

But still, the fact that there is no more active development, doesn't mean
it's obsolete. It still works fine as it ever did and there has been no need
to cut any of it's features for any reason.

Since logind works only on systemd, ConsoleKit is nothing less than what
dhcp-client is to dhcpcd. So, it's definately not 'deprecated', or
'obsolete'.
I call it 'mature'.

Many BSDs still use it, and with Xfce upstream including a OpenBSD
developer,
and Xfce's commitment to keeping it working with BSDs in otherway too,
I'm not worried about it becoming one of these nasty words of
'unmaintained',
'deprecated', 'obsolete' and co. even if I didn't do the legwork myself.

So no, we don't get to blame ConsoleKit for any of this what has been
happening.
Take my word for it, it's not going to go anywhere from Portage anyday soon.

But OK, it's a bit off-topic to this thread, I'm just getting ugly itch
when people
are so eager to call it anything else than mature despite it still
working fine.

- Samuli

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

17.02.2014 00:19, Canek Peláez Valdés пишет:
> On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> [ snip ]
>> Isn't there too many "if you believe" and "if you agree"? A church of
>> systemd? ;)
>
> As I said to Tanstaafl, it gets kind of philosophical.

Even religious.

> Technically, systemd is the obvious superior choice, and that's why
> the TC voted for it in Debian (read the discussion).

Oh I have read so many discussions already... :)
To me, systemd's technical superiority is far not obvious. Just another 
init system would be, but as long as systemd is much more that one, I 
can't say that. It should NOT be compared to OpenRC / upstart alone, 
rather to a whole bunch of tools it replaces, and probably even those 
it's ambitious to replace.

>> I wonder why all systemd's fancy stuff hasn't yet been integrated into any
>> existing init system, because of theoretical impossibility or just practical
>> uselessness?
>
> If it's "practically useless", why so many distributions keep choosing
> it? Why GNOME started using it?

Well, I said that technical superiority matters little for maintainers; 
what matters is money. If I'd write some super-puper fancy init system 
and kernel replacement, who would be interested? It's not the time of 
Linus' rise, now you don't deal with USENET freaks, but with Intel, 
RedHat and other billionaire corps. Do you have the guts and means to 
keep up with competitors, even not about kernel/init subsystems, but a 
user app like mailer/browser/messenger...
A kernel subsystem requires much more technical competence to maintain 
and is far more critical for functioning, so much more important here is 
not any 'technical superiority' but simply resources, human and 
financial, spared if using RH-maintained systemd.

>> Actually why not do the daemon management, logging, cron etc in the Linux
>> kernel itself? It's obvious, and we even have a perfect example of
>> kernel-integrated graphics around -- `guess the OS name`. It also has much
>> in common with systemd; "Believe us it's the best OS", "Believe us it
>> provides loads of features", "Agree with having binary logs" etc.
>
> All the software is libre; with only that any comparison to Microsoft
> becomes moot.

Once you mentioned "technical superiority", let's compare other stuff 
technically too. :)

>> A competent approach for choosing software for a task is answering the
>> questions:
>> 1. Is the software standards-compliant?
>> 2. Does the software have an alternative compatible implementation?
>> 3. Is the software developed to achieve a certain, concrete goal?
>> 4. Does the software achieve the goal?
>> 5. Does the software achieve the goal "gracefully"?
>> 6. Does the software have a clear perspective and view what it will be like?
>> 7. Is the software developed and maintained by a reliable company or group?
>
> That's *your* approach. It's certainly not my approach: I don't care
> if Emacs is "standards-compliant" (whatever that means for a text
> editor); I don't care if Inkscape has an alternative compatible
> implementation; and for the rest of your questions, my answer would be
> yes.

You don't care about Emacs and Inkscape but do you care the same nought 
about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks 
HTTP rather than SHiTP? Do you care that once after a couple of years 
your systems get unmaintained and unmaintainable because the software on 
them becomes a load of bashed up crap which only a world's head lennart 
can deal with? Well, you'll say that red hat tralala, but we've seen the 
rise and fall of many giants e.g. Sun with their once 'technically 
superior' Solaris and SPARCs, well one can name many I just don't have 
time, also we seen MySQL bought by Oracle, and all.
Nothing is eternal, and it's (Again!) quite not always technical matters 
that matters.

>> AFAICT, with systemd there's by far one "yes". The other answers are dubious
>> if just plain "no".
>
>  From your point of view.
>
>> I'd personally share Alan McKinnon's POV: there's no real reason to switch
>> to systemd since the present init systems serve pretty well and the benefit,
>> if any, isn't worth the adaptation threshold.
>
> That's fine; you don't have to use systemd. But if (as an extreme and
> unlikely example), Gentoo decided to switch exclusively to systemd,
> then either someone willing and able would need to come out ant start
> maintaining the alternatives, or then you should do it.

At present, no. But the trend is clear.

> That's how free software works.

Actually, free software (one you don't pay for) works like any other 
software you pay for. You probably wanted to say "that's how the OSS 
model works" but it's getting less and less true. The OSS model in many 
cases retains only its open source. Take MySQL, take KDE, take GNOME. 
Who cares about users? We do what we deem feasible regardless if you 
like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's 
technically superior. C'mon, who are you? An admin? A programmer? A 
Bachelor/PhD? Ha, man, we're BILLIONAIRES. That says it. We GRANT you 
our software AS IS. And its source. And its bugtrackers. We make 
business by the fact that we have millions of free testers 'round the 
world. We can afford that. If you can afford forking and maintaining, 
c'mon man.

>> But why then is Linux drifting to systemd? The answer is simple: money. Time
>> is money. You have to support two init systems -> twice the time, twice the
>> money. Sooner or later, a sum of money will outweigh the users' opinion. To
>> be a realist, one has to admit that in near future 90% of new distro
>> versions will be systemd-based. Unless some green soxx emerge and take over
>> Red Hat...
>
> I don't think neither time nor money had to do with Debian's (nor
> Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision.

It's not in terms "think" or "don't think". It's a fact.

> It's just technically superior. But's that's just my opinion, and what
> I believe ;)

That's a good thing to believe in. It's hard to prove, hard to see, 
impossible to test all cases.
Money is what you don't believe in. You either have it enough or not.

> So, amen? :D

Amen. :D

> Regards.
>

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

Thanks to all who chimed in...

On 2014-02-16 3:27 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Sun, Feb 16, 2014 at 1:26 PM, Mick <michaelkintzios@gmail.com> wrote:
> [snip]
>> You may have lost it in the link that Volker posted (thanks Volker), but this
>> comment from HaakonKL probably sums it up:
>>
>> "... I will give Upstart this though: Should something better come along, you
>> could replace upstart. I guess this holds true for OpenRC as well.
>>
>> You can't say that about systemd."

> I had read that blog entry before. Is full of errors, like believing
> that everything that systemd does is inside PID 1.

Maybe it is 'full of errors', but is the primary point true?

> There is actually little code inside PID 1;

The quoted text said nothing about this, so please stay on point.

As to the point raised:

>> Can you surgically remove systemd in the future without reverse engineering
>> half of what the LSB would look at the time, or will its developers ensure
>> that this is a one time choice only?

> You guys talk about software like if it was a big bad black magical
> box with inexplicable powers.
>
> If someone is willing and able, *everything* can be "surgically
> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
> and ESD. KDE got rid of aRts (and who knows what more).

I think you are being a little disingenuous here.

The obvious unspoken meaning behind the 'can you surgically remove' was:

Can you do it *easily*? I'm sure you would not suggest that getting rid 
of the above were 'easy'?

It simply doesn't matter if systemd boils down to one monolithic binary, 
or 600, if they are tied together in such a way that they can not 
*individually* be replaced *easily and simply* (ie, without having to 
rewrite the whole of systemd).

That said, it seems to me that, for now at least, it isn't that big a 
deal to switch back and forth between systemd and, for example, OpenRC.

So my main concern is - will it still be possible - *and* easy - in a 
year? Three years? Five? If the answer to *any* of those is no, then I 
think the best solution - for gentoo at least - is to make whether or 
not systemd is to be used more like a *profile* choice - a decision that 
you can make at install time, similar to choosing between hardened or 
not (not easy/simple to switch to/from after a system is up and running).

In fact, it seems to me that, since (from what I've read) the primary 
reason that systemd was written in the first place was to provide 
extremely fast boots *in virtualized environments*, having it be a 
choice made by selecting a corresponding *profile* is the *ideal* 
solution - at least for gentoo. At least this way everything could be 
documented, and switching between a systemd and non-systemd profile can 
be supported for as long as possible, understanding that at some point 
in time it may have to become an install time choice - kind of like 
choosing between hardened or not is mostly an install time choice now.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/17/2014 06:17 AM, Tanstaafl wrote:
> Thanks to all who chimed in...
> 
> On 2014-02-16 3:27 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Sun, Feb 16, 2014 at 1:26 PM, Mick <michaelkintzios@gmail.com> wrote:
>> [snip]
>>> You may have lost it in the link that Volker posted (thanks Volker),
>>> but this
>>> comment from HaakonKL probably sums it up:
>>>
>>> "... I will give Upstart this though: Should something better come
>>> along, you
>>> could replace upstart. I guess this holds true for OpenRC as well.
>>>
>>> You can't say that about systemd."
> 
>> I had read that blog entry before. Is full of errors, like believing
>> that everything that systemd does is inside PID 1.
> 
> Maybe it is 'full of errors', but is the primary point true?
> 
>> There is actually little code inside PID 1;
> 
> The quoted text said nothing about this, so please stay on point.
> 
> As to the point raised:
> 
>>> Can you surgically remove systemd in the future without reverse
>>> engineering
>>> half of what the LSB would look at the time, or will its developers
>>> ensure
>>> that this is a one time choice only?
> 
>> You guys talk about software like if it was a big bad black magical
>> box with inexplicable powers.
>>
>> If someone is willing and able, *everything* can be "surgically
>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
>> and ESD. KDE got rid of aRts (and who knows what more).
> 
> I think you are being a little disingenuous here.
> 
> The obvious unspoken meaning behind the 'can you surgically remove' was:
> 
> Can you do it *easily*? I'm sure you would not suggest that getting rid
> of the above were 'easy'?
> 
> It simply doesn't matter if systemd boils down to one monolithic binary,
> or 600, if they are tied together in such a way that they can not
> *individually* be replaced *easily and simply* (ie, without having to
> rewrite the whole of systemd).
> 
> That said, it seems to me that, for now at least, it isn't that big a
> deal to switch back and forth between systemd and, for example, OpenRC.
> 
> So my main concern is - will it still be possible - *and* easy - in a
> year? Three years? Five? If the answer to *any* of those is no, then I
> think the best solution - for gentoo at least - is to make whether or
> not systemd is to be used more like a *profile* choice - a decision that
> you can make at install time, similar to choosing between hardened or
> not (not easy/simple to switch to/from after a system is up and running).
> 
> In fact, it seems to me that, since (from what I've read) the primary
> reason that systemd was written in the first place was to provide
> extremely fast boots *in virtualized environments*, having it be a
> choice made by selecting a corresponding *profile* is the *ideal*
> solution - at least for gentoo. At least this way everything could be
> documented, and switching between a systemd and non-systemd profile can
> be supported for as long as possible, understanding that at some point
> in time it may have to become an install time choice - kind of like
> choosing between hardened or not is mostly an install time choice now.
> 

That's actually a really smart idea. It would allow for the integration
that systemd-fans desire and still respect the choice of people that
don't want systemd on their systems. Combined with USE flags and the
PORTDIR_MASK variable (iirc), it should create a "best of both worlds"
situation for Gentoo and a decision wouldn't need to be made. Despite my
distaste for systemd, I think this is a great middle ground that
everyone could, with some considerations or compromises, agree to.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 17/02/2014 14:17, Tanstaafl wrote:
> In fact, it seems to me that, since (from what I've read) the primary
> reason that systemd was written in the first place was to provide
> extremely fast boots *in virtualized environments*, having it be a
> choice made by selecting a corresponding *profile* is the *ideal*
> solution - at least for gentoo. At least this way everything could be
> documented, and switching between a systemd and non-systemd profile can
> be supported for as long as possible, understanding that at some point
> in time it may have to become an install time choice - kind of like
> choosing between hardened or not is mostly an install time choice now.

To me, this is as close to ideal as it can get.

As I said in my opening post, I do not suffer from the problem RedHat is
solving - my machines seldom reboot quicker than every 10 days
(including laptops) and OpenRC gets me to a useable prompt faster than
the BIOS takes to do it's thing :-)

A profile-like solution would suit me perfectly, something I can use or
not as I see fit and the choice made at install time.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Stroller]

On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> ...
> Whatever problems Red Hat are trying to solve in the Red Hat space are
> problems that do not affect me, so I do not need Red Hat's solution. As
> for Gnome, I have yet to see a valid reason why Gnome *must* use
> systemd; that is simply not true at all.

I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter).

Stroller.

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[»Q«]

On Mon, 17 Feb 2014 07:22:17 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> How long has it been since Debian decided to go with systemd? Like,
> three? So, up until three days ago I would have disagreed since
> despite original upstream ditching ConsoleKit, it was still being
> maintained by Debian and Gentoo maintainers (me) and last release,
> 0.4.6, was in fact a result of that.

And Debian hopefully will keep helping with any maintenance needed on
it.  They haven't decided to stop support of everything but systemd;
they've only decided systemd will be the default.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
[snip]
> Maybe it is 'full of errors', but is the primary point true?

False implies whatever you want it to imply. You can't prove anything
if your assumptions are incorrect.

>> There is actually little code inside PID 1;
>
>
> The quoted text said nothing about this, so please stay on point.

I was answering to someone else.

> As to the point raised:
>
>
>>> Can you surgically remove systemd in the future without reverse
>>> engineering
>>> half of what the LSB would look at the time, or will its developers
>>> ensure
>>> that this is a one time choice only?
>
>
>> You guys talk about software like if it was a big bad black magical
>> box with inexplicable powers.
>>
>> If someone is willing and able, *everything* can be "surgically
>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
>> and ESD. KDE got rid of aRts (and who knows what more).
>
>
> I think you are being a little disingenuous here.

I am not.

> The obvious unspoken meaning behind the 'can you surgically remove' was:
>
> Can you do it *easily*? I'm sure you would not suggest that getting rid of
> the above were 'easy'?

I've never said it was easy. I said it could be done by someone
willing and able. I repeated that like five times I think. I said it
was done before; I never said it was easy.

But it can be done, and that's a indisputable fact.

> It simply doesn't matter if systemd boils down to one monolithic binary, or
> 600, if they are tied together in such a way that they can not
> *individually* be replaced *easily and simply* (ie, without having to
> rewrite the whole of systemd).

You are setting a group of conditions that preemptively wants to stop
adoption of anything that is tightly integrated. That is a losing
strategy (different projects actually *want* tight integration), and
besides the burden of work should not fall on the people wanting to
use a tightly integrated stack.

You want individual modules that are "easily and simply" replaced?
Then WROTE THEM. Don't expect the systemd authors (or any other) to do
it for you.

> That said, it seems to me that, for now at least, it isn't that big a deal
> to switch back and forth between systemd and, for example, OpenRC.

It depends; right now you can't switch back and forth between OpenRC
and systemd without reemerging some stuff. Some of those packages
*could* be made to switch functionality at run time instead of compile
time, but SOMEONE has to write that support, and it's probably that
the upstream for the package will not accept those changes, since for
binary distributions it makes no sense to have the complexity on the
code of switching behavior at runtime when doing at compile time is
easier and the distribution generates one binary per architecture for
all its users.

> So my main concern is - will it still be possible - *and* easy - in a year?
> Three years? Five? If the answer to *any* of those is no, then I think the
> best solution - for gentoo at least - is to make whether or not systemd is
> to be used more like a *profile* choice - a decision that you can make at
> install time, similar to choosing between hardened or not (not easy/simple
> to switch to/from after a system is up and running).

That's how it works right now, because Gentoo developers *did* the
work. And the whole point of my "willing and able" mantra is to see if
someone here steps up into the plate.

It's *really* easy to say "oh, systemd should be provided by a profile
so the user is free to CHOICE if she wants to use it or not", but
*someone* has to write the necessary support so that the profile
actually exists. You want to be sure your choice is not "taken away"
from you? Join Gentoo and help to make that choice possible.

Don't expect that someone will do it for you.

There is a lengthy discussion in gentoo-dev about the problem with
understaffed arch teams. It's worth a reading, but the general
consensus is that the minor archs cannot be kept in stable if there
are not enough developers for said arch to do the testing.

It sucks? Of course it sucks; but there is no magical fairy that
automatically will keep working all the ebuilds for all the archs in
Gentoo. SOMEONE has to do the testing, someone has to triage bugs,
someone has to *fix* them.

If there is no one, then the arch cannot be kept in stable. And that's
a hard cold fact.

If *all* the Gentoo developers switched to systemd (highly unlikely),
then how could they support a separated profile for systemd? They
won't, and your "choice" will then be "taken away".

If the Gentoo developers decide that having systemd in a separated
profile is too much work (likely, even now), then what? More whining
from users because they "took away" their "choice"?

They could whine all they want, but if nobody steps up to the plate to
do the actual work, nobody (necessarily) will do it for them.

> In fact, it seems to me that, since (from what I've read) the primary reason
> that systemd was written in the first place was to provide extremely fast
> boots *in virtualized environments*,

You are wrong; systemd was created because Upstart had the silly CLA
from Canonical[1], and because its authors wanted a novel init system
for Linux (and Linux only) that used all the cool technologies the
kernel provides, and that it could solve problems like: how to easily
and consistently start daemons with well defined semantics for its
dependencies; how to easily and consistently apply resource quotas to
them; how to deal with modern computers where hardware comes and goes
(including CPUs) all the time, etc. [2].

> having it be a choice made by selecting
> a corresponding *profile* is the *ideal* solution - at least for gentoo. At
> least this way everything could be documented, and switching between a
> systemd and non-systemd profile can be supported for as long as possible,
> understanding that at some point in time it may have to become an install
> time choice - kind of like choosing between hardened or not is mostly an
> install time choice now.

That profile idea sounds even reasonable. But I don't think the devs
will implement it, since simple dependencies seems to work up until
now, and *someone* would need to write the profile, and *someone*
would need to test it, and *someone* would need to triage bugs for it,
and *someone* would need to fix them.

If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
it would happen.

But don't complain if no one does, and it doesn't.

Regards.

[1] https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq
[2] http://0pointer.de/blog/projects/systemd.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
> > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
> >> <volkerarmin@googlemail.com> wrote:
> >> [ snip ]
> >>> or it is an idiotic decision. Because features means complexity.
> >> Yeah, like the kernel.
> >>
> >>> Complexity means bugs.
> >> Bugs get reported, bugs get fixes. Life goes on.
> 
> You didn't answered this, did you?

Bugs are different. Bugs in the critical system components are
critical to the whole system. If Libreoffice or browser
segfaults, some data may be lost and inconvenience created, but the
system will continue to run. If PID 1 segfaults — everything is
lost, you have a kernel panic. That's why critical components should
be as simple and clean as possible.

SysVinit code size is about 10 000 lines of code, OpenRC contains
about 13 000 lines, systemd — about 200 000 lines. Even assuming
systemd code is as mature as sysvinit or openrc (though I doubt this)
you can calculate probabilities of segfaults yourself easily.

> >> All of them are different tools providing one capability to systemd as
> >> a whole. So systemd is a collection of tools, where each one does one
> >> thing, and it does it well.
> >>
> >> By your definition, systemd perfectly follows "the unix way".
> >>
> >
> > no, it isn't.
> >
> > How are those binaries talk to each other?
> 
> dbus, which is about to be integrated into the kernel with kdbus.

And this is a very, very bad idea. Looks like you don't know matter at
all: to begin with kdbus protocol is NOT compatible dbus and special
converter daemon will be needed to enable dbus to talk to kdbus. The
whole kdbus technology is very questionable itself (and was
forcefully pushed by RH devs), anyway it is possible to disable this
stuff in kernel and guess what will be done on my systems.

> > Looks broken. Broken by design. The worst form of broken.
> 
> By your opinion, not others.

That is not just an opinion. There is a science and experience behind
system's design. And all that science was ignored during systemd
architecture process if there was any at all.
 
Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4944 bytes --]

On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote:
> > It simply doesn't matter if systemd boils down to one monolithic binary, or
> > 600, if they are tied together in such a way that they can not
> > *individually* be replaced *easily and simply* (ie, without having to
> > rewrite the whole of systemd).
> 
> You are setting a group of conditions that preemptively wants to stop
> adoption of anything that is tightly integrated. That is a losing
> strategy (different projects actually *want* tight integration), and
> besides the burden of work should not fall on the people wanting to
> use a tightly integrated stack.
> 
> You want individual modules that are "easily and simply" replaced?
> Then WROTE THEM. Don't expect the systemd authors (or any other) to do
> it for you.

And here we have a small problem: for modules to be replaceable the
core system should be designed to support replaceable modules, but
systemd is not. The whole deep integration approach and lack of
inter-module boundaries doesn't allow one to write replaceable blocks
without crazy hacking.

Just imagine that one have PCI-E bus and this bug is being replaced
with some other PC-systemd bus, where one have to interface each
component differently. And if one removes e.g. audio card some other
seemingly independent component e.g. network controller becomes
broken. That is the nature of systemd and that is many people dislike
this technology.

> > That said, it seems to me that, for now at least, it isn't that big a deal
> > to switch back and forth between systemd and, for example, OpenRC.
> 
> It depends; right now you can't switch back and forth between OpenRC
> and systemd without reemerging some stuff. Some of those packages
> *could* be made to switch functionality at run time instead of compile
> time, but SOMEONE has to write that support, and it's probably that
> the upstream for the package will not accept those changes, since for
> binary distributions it makes no sense to have the complexity on the
> code of switching behavior at runtime when doing at compile time is
> easier and the distribution generates one binary per architecture for
> all its users.

The most sane and fair solution was already proposed: create a
systemd profile for those who need it. I personally highly dislike
systemd technology, but I respect the right of other to shoot them in
the leg (or head) as much as they want to. This is Gentoo: a universal
constructor providing people means to build any system in any shape
they need.

Unfortunately chances are that in future some software may become
unusable or unsupported outside of systemd profile. But patches may
be created and other profiles will continue to live the same way
hardened exists now and will continue to exist later.

BTW it was shown at the recent LVEE Winter 2014 conference that GDM
can be easily freed from systemd and OpenBSD guys have an interesting
idea for faking systemd presence for applications requesting one
mandatory. Though IMO any end-user application strictly dependable on
any init system is broken by design: for a daemon there should be no
difference by which tool it was started.

> > In fact, it seems to me that, since (from what I've read) the primary reason
> > that systemd was written in the first place was to provide extremely fast
> > boots *in virtualized environments*,
> 
> You are wrong; systemd was created because Upstart had the silly CLA
> from Canonical[1], and because its authors wanted a novel init system
> for Linux (and Linux only) that used all the cool technologies the
> kernel provides, and that it could solve problems like: how to easily
> and consistently start daemons with well defined semantics for its
> dependencies; how to easily and consistently apply resource quotas to
> them; how to deal with modern computers where hardware comes and goes
> (including CPUs) all the time, etc. [2].

Excuse me please, but what you wrote above is very naive. All that
reasons are just an excuse. The real reason is money: systemd is a Red
Hat project (despite being formally open for everyone) and is their
tool^Wweapon to fight with Canonical for a sales market. It the last
years RH was pushed near even in a server market and now they are
fighting back. They were lucky enough to acquire Poettiring guy and
create from a simple and sound sysvinit (which is an important but
not dictating peace of software) a key component where they can
dictate their own line, where they can lead all Linux community in
a way they need.

That the real reason I despise systemd: in replaces the freedom of
choice by a dictatorship of a small bunch of managers of a single
corporation (yes, managers, not developers). And all this is under the
veil of GPL and technical merits. This is the poison in the well of
FOSS.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

Sorry for entering others' dialog...

On 17.02.2014 21:13, Canek Peláez Valdés wrote:
> On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> [snip]
>>>> Can you surgically remove systemd in the future without reverse
>>>> engineering
>>>> half of what the LSB would look at the time, or will its developers
>>>> ensure
>>>> that this is a one time choice only?
>>
>>
>>> You guys talk about software like if it was a big bad black magical
>>> box with inexplicable powers.
>>>
>>> If someone is willing and able, *everything* can be "surgically
>>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
>>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
>>> and ESD. KDE got rid of aRts (and who knows what more).
>>
>>
>> I think you are being a little disingenuous here.
>
> I am not.
>
>> The obvious unspoken meaning behind the 'can you surgically remove' was:
>>
>> Can you do it *easily*? I'm sure you would not suggest that getting rid of
>> the above were 'easy'?
>
> I've never said it was easy. I said it could be done by someone
> willing and able. I repeated that like five times I think. I said it
> was done before; I never said it was easy.

The whole point of creating new software is making things easier. Easier 
to use, easier to maintain, easier to remove.

> But it can be done, and that's a indisputable fact.

A total ground-up rewrite of the whole Linux is also quite possible.

>> It simply doesn't matter if systemd boils down to one monolithic binary, or
>> 600, if they are tied together in such a way that they can not
>> *individually* be replaced *easily and simply* (ie, without having to
>> rewrite the whole of systemd).
>
> You are setting a group of conditions that preemptively wants to stop
> adoption of anything that is tightly integrated. That is a losing
> strategy (different projects actually *want* tight integration), and
> besides the burden of work should not fall on the people wanting to
> use a tightly integrated stack.

How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* 
integration, *standards* integration not *software* integration. You do 
want tight integration where it just can't work otherwise, but the 
design of Unix provides (well, again repeating this), and almost any 
robust design should provide, the ignorance of one abstraction level 
about another. Why HAL? Why udev? Why drivers as modules? Why not just 
go and integrate all stuff into the kernel, well (again!) like MS do, 
and don't please say I compare wrong things just because MS is not OSS.

> You want individual modules that are "easily and simply" replaced?
> Then WROTE THEM. Don't expect the systemd authors (or any other) to do
> it for you.

We really don't expect that systemd's authors do anything for us. 
Anything they do is not for us, thanks.

>> That said, it seems to me that, for now at least, it isn't that big a deal
>> to switch back and forth between systemd and, for example, OpenRC.

"For now" it's not, but take a look into the future when not a single 
product will be published without systemd's support, just because it's 
everywhere -- and since it's everywhere, then why bother support 
anything other? Time, money... So it's a matter of time -- you'll 
personally be happy with this scenario -- at first -- but think 
further... They'll be able to stuff everything into it, making 
effectively a thing in itself which will dictate you where to go and 
what to do, just because you're not technically competent enough to deal 
with it -- hence more support calls and more $ etc etc. I don't believe 
in Red Hat's being a corporation of Good, nor any other corporation 
being such, and please remember the notorious examples of almost 
privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost 
OpenOffice...)
Well, there's some probability that by the time systemd occupies all 
linux distros, some clever RH guy (or a green soxx guy) will emerge and 
emerge systemd v2 which will be different ... But it's not something one 
should count on.

>  [...]
> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
> it would happen.
>
> But don't complain if no one does, and it doesn't.

That's your point -- and mine. We aren't complaining -- we want to 
prevent this. The forward-looking people must unite, it may sound 
ridiculous, against systemd -- not because of its design, technical 
details etc, but because otherwise in short time you'll end up comparing 
systemd to itself. You know what it is: everything's free but nothing to 
choose from. We had it before, it's called communism. Maybe it is not 
that bad but we don't want it anymore.

> Regards.


-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-17 12:52 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> And this is a very, very bad idea. Looks like you don't know matter at
> all: to begin with kdbus protocol is NOT compatible dbus and special
> converter daemon will be needed to enable dbus to talk to kdbus. The
> whole kdbus technology is very questionable itself (and was
> forcefully pushed by RH devs), anyway it is possible to disable this
> stuff in kernel and guess what will be done on my systems.

Forcefully? Are you saying that *anyone* can *force* Linus to put 
something into the kernel?

I'd also really, *really* like to hear a *recent* opinion from Linus on 
systemd...

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 17/02/2014 17:29, Stroller wrote:
> 
> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> ...
>> Whatever problems Red Hat are trying to solve in the Red Hat space are
>> problems that do not affect me, so I do not need Red Hat's solution. As
>> for Gnome, I have yet to see a valid reason why Gnome *must* use
>> systemd; that is simply not true at all.
> 
> I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter).

That was the classic rationale for "no separate /usr without an initrd"
in udev - the claimed need to have any arbitrary runnable code available
to be run before the entire system is up and running.

Red Hat's reasons for pushing systemd are more fuzzy and nothing I've
read so far tells me we have the full picture. Two things seem highly
plausible:

1. An init system that can use modern features of the Linux kernel (most
often Linux-only at this point) like cgroups
2. Extremely fast boot times to spin up virtual machines in a fraction
of the time it currently takes.

#1 may or may not be desirable, I honestly don't know. What I have seen
is a lot of theory and not much reproducable fact.
#2 is highly desirable if you run massive VM farms; folks like google,
rh and amazon would be very interested. Doesn't really sound like a
valid reason to consume and replace the entire existing ecosystem
though. How many googles, red hats and amazons are out there versus how
many regular joes like thee and me? Why didn't red hat just write their
magic sauce to be non-intrusive? Profit and politics I suppose, I really
don't see a valid overarching technical reason why it *must* be so.




-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Mon, 17 Feb 2014 14:52:33 -0500 Tanstaafl wrote:
> On 2014-02-17 12:52 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> > And this is a very, very bad idea. Looks like you don't know matter at
> > all: to begin with kdbus protocol is NOT compatible dbus and special
> > converter daemon will be needed to enable dbus to talk to kdbus. The
> > whole kdbus technology is very questionable itself (and was
> > forcefully pushed by RH devs), anyway it is possible to disable this
> > stuff in kernel and guess what will be done on my systems.
> 
> Forcefully? Are you saying that *anyone* can *force* Linus to put 
> something into the kernel?

OK, my choice of words was not appropriate. I mean that not every
kernel dev is happy that kdbus is in the kernel now.

> I'd also really, *really* like to hear a *recent* opinion from Linus on 
> systemd...

Judging from his previous opinions this one is unlikely to be systemd-
friendly.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
>> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
>> <volkerarmin@googlemail.com> wrote:
>> > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
>> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
>> >> <volkerarmin@googlemail.com> wrote:
>> >> [ snip ]
>> >>> or it is an idiotic decision. Because features means complexity.
>> >> Yeah, like the kernel.
>> >>
>> >>> Complexity means bugs.
>> >> Bugs get reported, bugs get fixes. Life goes on.
>>
>> You didn't answered this, did you?
>
> Bugs are different.

Bugs are bugs, period. And they get reported and fixed.

> Bugs in the critical system components are
> critical to the whole system.

Yeah, that's why we have unit testing and QA teams and stable and
unstable releases, etc.

> If Libreoffice or browser
> segfaults, some data may be lost and inconvenience created, but the
> system will continue to run. If PID 1 segfaults — everything is
> lost, you have a kernel panic.

And the world will end? The same happens if the kernel has an error.

> That's why critical components should
> be as simple and clean as possible.

Like the kernel? You call that "simple"?

I'm sorry, but you are (IMO) wrong: critical components should be
thoroughly tested and debugged, and have integrated unit testing, and
a large enough group of volunteers to test new releases before they go
into the general public.

> SysVinit code size is about 10 000 lines of code, OpenRC contains
> about 13 000 lines, systemd — about 200 000 lines.

If you take into account the thousands of shell code that SysV and
OpenRC need to fill the functionality of systemd, they use even more.

Also, again, systemd have a lot of little binaries, many of them
optional. The LOC of PID 1 is actually closer to SysV (although still
bigger).

> Even assuming
> systemd code is as mature as sysvinit or openrc (though I doubt this)
> you can calculate probabilities of segfaults yourself easily.

I don't care about probabilities; I care about facts: FACT, I've been
using systemd since 2010, in several machines, and I haven't had a
single segfault. FACT: almost no bug report in systemd involves a
segfault in PID 1.

>> >> All of them are different tools providing one capability to systemd as
>> >> a whole. So systemd is a collection of tools, where each one does one
>> >> thing, and it does it well.
>> >>
>> >> By your definition, systemd perfectly follows "the unix way".
>> >>
>> >
>> > no, it isn't.
>> >
>> > How are those binaries talk to each other?
>>
>> dbus, which is about to be integrated into the kernel with kdbus.
>
> And this is a very, very bad idea. Looks like you don't know matter at
> all: to begin with kdbus protocol is NOT compatible dbus and special
> converter daemon will be needed to enable dbus to talk to kdbus.

kdbus uses a different wire protocol than dbus; but for clients that
doesn't matter; libsystemd-dbus will offer a compatibility layer (talk
about "standard" and "replaceable"), so if your application uses dbus
today, it will work with kdbus.

Of course, new applications will take advantage of the new features of kdbus.

> The
> whole kdbus technology is very questionable itself (and was
> forcefully pushed by RH devs),

Sorry, but it's you who doesn't know the matter at hand: kdbus was
(and is) written by Greg Kroah-Hartman, Linus' right hand, and who
works for the Linux Foundation.

> anyway it is possible to disable this
> stuff in kernel and guess what will be done on my systems.

Good for you. Guess what will be done in mine?

>> > Looks broken. Broken by design. The worst form of broken.
>>
>> By your opinion, not others.
>
> That is not just an opinion. There is a science and experience behind
> system's design.

Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
or Keith Packard of X.org fame? None of them works for Red Hat; both
of them know more about Unix and Linux than you and me together, and
both of them promote systemd.

I mean, I myself know a thing or two about computing and Linux, and I
promote systemd (and nobody pays me, BTW), but obviously you don't
need to believe in my credentials.

And, no offense, but I will always give more weight to the words of
Greg Kroah-Hartman or Keith Packard (to name only two), instead of a
random user in gentoo-user.

There are knowledgeable people who are against systemd. But usually
they don't give *technical* sound reasons.

> And all that science was ignored during systemd
> architecture process if there was any at all.

You should read systemd-devel and Lennart's blog posts before saying
something like that. I did.

Regards
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 17, 2014 at 12:24 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote:
>> > It simply doesn't matter if systemd boils down to one monolithic binary, or
>> > 600, if they are tied together in such a way that they can not
>> > *individually* be replaced *easily and simply* (ie, without having to
>> > rewrite the whole of systemd).
>>
>> You are setting a group of conditions that preemptively wants to stop
>> adoption of anything that is tightly integrated. That is a losing
>> strategy (different projects actually *want* tight integration), and
>> besides the burden of work should not fall on the people wanting to
>> use a tightly integrated stack.
>>
>> You want individual modules that are "easily and simply" replaced?
>> Then WROTE THEM. Don't expect the systemd authors (or any other) to do
>> it for you.
>
> And here we have a small problem: for modules to be replaceable the
> core system should be designed to support replaceable modules, but
> systemd is not.

You misunderstood me: I didn't mean to say that someone should write a
module to replace one of systemd's modules. I mean that distributions
and projects are using systemd's features, and that if you want those
features to be "easily and simply" replaceable, then someone needs to
write them like that. Systemd developers decided the tightly
integrated route; if you don't like that, and that the distributions
are using systemd's features, write something similar being "easily
and simply" replaceable so the distros don't need to use systemd.

> The whole deep integration approach and lack of
> inter-module boundaries doesn't allow one to write replaceable blocks
> without crazy hacking.

Well, then go and show them how it's done. And please don't say that
"it's already done", because if that were the case, no distro would
have adopted systemd.

They adopted it because of the features it offers.

> Just imagine that one have PCI-E bus and this bug is being replaced
> with some other PC-systemd bus, where one have to interface each
> component differently. And if one removes e.g. audio card some other
> seemingly independent component e.g. network controller becomes
> broken. That is the nature of systemd and that is many people dislike
> this technology.

That is a broken analogy; if logind has a bug, that doesn't affect
timedated, nor udev.

>> > That said, it seems to me that, for now at least, it isn't that big a deal
>> > to switch back and forth between systemd and, for example, OpenRC.
>>
>> It depends; right now you can't switch back and forth between OpenRC
>> and systemd without reemerging some stuff. Some of those packages
>> *could* be made to switch functionality at run time instead of compile
>> time, but SOMEONE has to write that support, and it's probably that
>> the upstream for the package will not accept those changes, since for
>> binary distributions it makes no sense to have the complexity on the
>> code of switching behavior at runtime when doing at compile time is
>> easier and the distribution generates one binary per architecture for
>> all its users.
>
> The most sane and fair solution was already proposed: create a
> systemd profile for those who need it. I personally highly dislike
> systemd technology, but I respect the right of other to shoot them in
> the leg (or head) as much as they want to. This is Gentoo: a universal
> constructor providing people means to build any system in any shape
> they need.

If someone willing and able provides any choice, that choice will be available.

> Unfortunately chances are that in future some software may become
> unusable or unsupported outside of systemd profile. But patches may
> be created and other profiles will continue to live the same way
> hardened exists now and will continue to exist later.

Yeah, and that's my whole point: if you want that the world outside of
systemd keeps working, you need to step in. Complaining about systemd
will get no one nowhere.

> BTW it was shown at the recent LVEE Winter 2014 conference that GDM
> can be easily freed from systemd and OpenBSD guys have an interesting
> idea for faking systemd presence for applications requesting one
> mandatory. Though IMO any end-user application strictly dependable on
> any init system is broken by design: for a daemon there should be no
> difference by which tool it was started.

GNOME depends on logind, not systemd. And no one has been willing and
able to produce a compatible replacement: logind works with a dbus
API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu
has been working in a replacement, but (AFAIU) is not finished.

>> > In fact, it seems to me that, since (from what I've read) the primary reason
>> > that systemd was written in the first place was to provide extremely fast
>> > boots *in virtualized environments*,
>>
>> You are wrong; systemd was created because Upstart had the silly CLA
>> from Canonical[1], and because its authors wanted a novel init system
>> for Linux (and Linux only) that used all the cool technologies the
>> kernel provides, and that it could solve problems like: how to easily
>> and consistently start daemons with well defined semantics for its
>> dependencies; how to easily and consistently apply resource quotas to
>> them; how to deal with modern computers where hardware comes and goes
>> (including CPUs) all the time, etc. [2].
>
> Excuse me please, but what you wrote above is very naive.

So you say.

> All that reasons are just an excuse.

So you say.

> The real reason is money: systemd is a Red
> Hat project (despite being formally open for everyone) and is their
> tool^Wweapon to fight with Canonical for a sales market. It the last
> years RH was pushed near even in a server market and now they are
> fighting back.

Nice conspiracy theory you have going on.

> They were lucky enough to acquire Poettiring guy and
> create from a simple and sound sysvinit (which is an important but
> not dictating peace of software) a key component where they can
> dictate their own line, where they can lead all Linux community in
> a way they need.

And it gets better. Citation needed? Any hard proof?

> That the real reason I despise systemd: in replaces the freedom of
> choice by a dictatorship of a small bunch of managers of a single
> corporation (yes, managers, not developers). And all this is under the
> veil of GPL and technical merits. This is the poison in the well of
> FOSS.

I don't work for RedHat; I teach in a University. Nobody pays me for
using systemd; I just choose to because I think is a technical sound
solution for the chaos that was the plumbing layer in Linux. So do
people like Greg Kroah-Hartman and Keith Packard, and many more
technical knowledgeable people.

If you want to believe your little conspiracy theory, that's fine; but
you are covering the sun with a finger.

The technical merits and advantages of systemd are there in the open
for anyone willing to study a little about it. *After* you carefully
read the code, the documentation, and test the software in real life,
you *may* still think you don't like the software or its design.

But you will be with the minority of the people who have done their homework.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 17, 2014 at 12:28 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> Sorry for entering others' dialog...
>
>
> On 17.02.2014 21:13, Canek Peláez Valdés wrote:
>>
>> On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tanstaafl@libertytrek.org>
>> wrote:
>> [snip]
>>>>>
>>>>> Can you surgically remove systemd in the future without reverse
>>>>>
>>>>> engineering
>>>>> half of what the LSB would look at the time, or will its developers
>>>>> ensure
>>>>> that this is a one time choice only?
>>>
>>>
>>>
>>>> You guys talk about software like if it was a big bad black magical
>>>> box with inexplicable powers.
>>>>
>>>> If someone is willing and able, *everything* can be "surgically
>>>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
>>>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
>>>> and ESD. KDE got rid of aRts (and who knows what more).
>>>
>>>
>>>
>>> I think you are being a little disingenuous here.
>>
>>
>> I am not.
>>
>>> The obvious unspoken meaning behind the 'can you surgically remove' was:
>>>
>>> Can you do it *easily*? I'm sure you would not suggest that getting rid
>>> of
>>> the above were 'easy'?
>>
>>
>> I've never said it was easy. I said it could be done by someone
>> willing and able. I repeated that like five times I think. I said it
>> was done before; I never said it was easy.
>
>
> The whole point of creating new software is making things easier. Easier to
> use, easier to maintain, easier to remove.

Well, systemd is easier to use after a little time learning how it
works. And it seems to be easier to maintain that thousands of lines
of spaghetti shell code. And, I'm sorry, did you just said "easier to
remove"? Seriously?

You think the kernel is "easier to remove"? Or glibc?

>
>> But it can be done, and that's a indisputable fact.
>
>
> A total ground-up rewrite of the whole Linux is also quite possible.

Of course it is; that's the beauty of free (libre) software.

>
>
>>> It simply doesn't matter if systemd boils down to one monolithic binary,
>>> or
>>> 600, if they are tied together in such a way that they can not
>>> *individually* be replaced *easily and simply* (ie, without having to
>>> rewrite the whole of systemd).
>>
>>
>> You are setting a group of conditions that preemptively wants to stop
>> adoption of anything that is tightly integrated. That is a losing
>> strategy (different projects actually *want* tight integration), and
>> besides the burden of work should not fall on the people wanting to
>> use a tightly integrated stack.
>
>
> How Integrated? The TCP/IP stack *is* integrated. But it is *protocol*
> integration, *standards* integration not *software* integration. You do want
> tight integration where it just can't work otherwise, but the design of Unix
> provides (well, again repeating this), and almost any robust design should
> provide, the ignorance of one abstraction level about another. Why HAL? Why
> udev? Why drivers as modules? Why not just go and integrate all stuff into
> the kernel, well (again!) like MS do, and don't please say I compare wrong
> things just because MS is not OSS.

You make a wrong comparison, because MS is not free (libre) software.
With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we
have been able to try new technologies (and see that some of them
fail, like HAL [yuck!]), because we have the source.

As you said, you can replace the whole of Linux if you so desire (and
have the technical ability).

You will never be able to do that with any MS software, and so the
comparison makes no sense.

>
>> You want individual modules that are "easily and simply" replaced?
>> Then WROTE THEM. Don't expect the systemd authors (or any other) to do
>> it for you.
>
>
> We really don't expect that systemd's authors do anything for us. Anything
> they do is not for us, thanks.

Sorry, but they do. Read the mailing list. Feature requests, bugs,
they do it for their users. Every time a new distro chooses systemd as
init, the developers try to help the maintainers to integrate systemd
to it.

>>> That said, it seems to me that, for now at least, it isn't that big a
>>> deal
>>> to switch back and forth between systemd and, for example, OpenRC.
>
>
> "For now" it's not, but take a look into the future when not a single
> product will be published without systemd's support, just because it's
> everywhere -- and since it's everywhere, then why bother support anything
> other? Time, money...

If enough people, willing and able, want to do it, they will. Look at
ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD.

The thing (and that's also my point), apparently *most* of the people
willing and able to create cool software have decided that systemd is
the way to go. And, even if you want to attribute that to a simple
monetary issue, most of them do it *happily* because many things are
just easier to do with systemd.

> So it's a matter of time -- you'll personally be happy
> with this scenario -- at first -- but think further...

I do. All the time, since 1996 when I started using Linux.

> They'll be able to
> stuff everything into it, making effectively a thing in itself which will
> dictate you where to go and what to do, just because you're not technically
> competent enough to deal with it -- hence more support calls and more $ etc
> etc.

Oh, but nobody will be able to do that to me. I know how to write
code. I'm willing (and I believe able) to write and/or modify software
if I don't like how it does things. I've done it before; I could do it
again.

The thing is, with Linux+systemd+GNOME I need to do it less and less
with every new release. The developers of the whole stack are bringing
Linux to where I have always wanted it to be.

 I don't believe in Red Hat's being a corporation of Good, nor any other
> corporation being such, and please remember the notorious examples of almost
> privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost
> OpenOffice...)

I don't care about RedHat; I used that distribution a couple of years
before moving to Mandrake, and then finally to Gentoo in 2002. I don't
care about them; I care about Linux, and Gentoo. And *nothing* that
RedHat does or stops doing it affect Gentoo nor Linux in the negative,
from my point of view.

> Well, there's some probability that by the time systemd occupies all linux
> distros, some clever RH guy (or a green soxx guy) will emerge and emerge
> systemd v2 which will be different ... But it's not something one should
> count on.

If someone is willing and able to write something better than system, THEY WILL.

>>  [...]
>>
>> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
>> it would happen.
>>
>> But don't complain if no one does, and it doesn't.
>
>
> That's your point -- and mine. We aren't complaining -- we want to prevent
> this.

Prevent what? People writing new software that offers cool features,
and therefore distros are using them?

> The forward-looking people must unite, it may sound ridiculous,
> against systemd

You cannot stop people for writing new cool stuff, nor distros for
wanting to using them. You CAN write your own cool stuff, and
convincing people that is better than the alternative.

But you have to offer *at least* the same features than the
competition. That's why *nobody* on Debian's TC choose OpenRC above
Upstart and systemd.

> -- not because of its design, technical details etc, but
> because otherwise in short time you'll end up comparing systemd to itself.

?

> You know what it is: everything's free but nothing to choose from. We had it
> before, it's called communism. Maybe it is not that bad but we don't want it
> anymore.

(Really? A cold war reference?)

The code is out there. You can choose to pick any point in time of the
whole stack (ca. 2009, before systemd existed), and wrote from there
if you have enough people willing and able to.

No one is taking anything from any one. No one is forcing nothing.

Free software is being written and offered, and knowledgeable people
are choosing to use it in their distros.

You are against that? Then wrote your own version with the same (or
better) features.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Mon, 17 Feb 2014 18:35:34 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko
> <bircoph@gmail.com> wrote:
> > On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
> >> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> >> <volkerarmin@googlemail.com> wrote:
> >> > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
> >> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
> >> >> <volkerarmin@googlemail.com> wrote:
> >> >> [ snip ]
> >> >>> or it is an idiotic decision. Because features means
> >> >>> complexity.
> >> >> Yeah, like the kernel.
> >> >>
> >> >>> Complexity means bugs.
> >> >> Bugs get reported, bugs get fixes. Life goes on.
> >>
> >> You didn't answered this, did you?
> >
> > Bugs are different.
> 
> Bugs are bugs, period. And they get reported and fixed.
> 
> > Bugs in the critical system components are
> > critical to the whole system.
> 
> Yeah, that's why we have unit testing and QA teams and stable and
> unstable releases, etc.
> 
> > If Libreoffice or browser
> > segfaults, some data may be lost and inconvenience created, but the
> > system will continue to run. If PID 1 segfaults — everything is
> > lost, you have a kernel panic.
> 
> And the world will end? The same happens if the kernel has an error.
> 
> > That's why critical components should
> > be as simple and clean as possible.
> 
> Like the kernel? You call that "simple"?
> 
> I'm sorry, but you are (IMO) wrong: critical components should be
> thoroughly tested and debugged, and have integrated unit testing, and
> a large enough group of volunteers to test new releases before they go
> into the general public.

How can you be sure if something is "large enough" if, as you say below,
you do not care about probabilities?

> > SysVinit code size is about 10 000 lines of code, OpenRC contains
> > about 13 000 lines, systemd — about 200 000 lines.
> 
> If you take into account the thousands of shell code that SysV and
> OpenRC need to fill the functionality of systemd, they use even more.
> 
> Also, again, systemd have a lot of little binaries, many of them
> optional. The LOC of PID 1 is actually closer to SysV (although still
> bigger).
> 
> > Even assuming
> > systemd code is as mature as sysvinit or openrc (though I doubt
> > this) you can calculate probabilities of segfaults yourself easily.
> 
> I don't care about probabilities;

If you do not care (= do not now anything) about probabilities
(and mathematics, in general), you just unable to understand
that debugging a program with 200K lines of code take

200000!/(10000!)^20

more time than debugging of 20 different programs with 10K lines of
code. You can try to calculate that number yourself but I quite sure
that if the latter can take, say, 20 days, the former can take
millions of years.

It is all the probability! Or, to be more precise, combinatorics.  

> I care about facts: FACT, I've been using systemd since 2010,
> in several machines, and I haven't had a single segfault.

Have you ever tried forex? If yes, you should have been warned
that "no past performance guarantee the future one."

And if you do not believe that (and do not care about probability
and all the stuff like that), you should visit any of the forex forums
where you will be suggested a magical money winning strategy that, in
the past, behaved very well and earned 200 or even 500% a month.

> FACT: almost no bug report in systemd involves a
> segfault in PID 1.
> 
> >> >> All of them are different tools providing one capability to
> >> >> systemd as a whole. So systemd is a collection of tools, where
> >> >> each one does one thing, and it does it well.
> >> >>
> >> >> By your definition, systemd perfectly follows "the unix way".
> >> >>
> >> >
> >> > no, it isn't.
> >> >
> >> > How are those binaries talk to each other?
> >>
> >> dbus, which is about to be integrated into the kernel with kdbus.
> >
> > And this is a very, very bad idea. Looks like you don't know matter
> > at all: to begin with kdbus protocol is NOT compatible dbus and
> > special converter daemon will be needed to enable dbus to talk to
> > kdbus.
> 
> kdbus uses a different wire protocol than dbus; but for clients that
> doesn't matter; libsystemd-dbus will offer a compatibility layer (talk
> about "standard" and "replaceable"), so if your application uses dbus
> today, it will work with kdbus.
> 
> Of course, new applications will take advantage of the new features
> of kdbus.
> 
> > The
> > whole kdbus technology is very questionable itself (and was
> > forcefully pushed by RH devs),
> 
> Sorry, but it's you who doesn't know the matter at hand: kdbus was
> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
> works for the Linux Foundation.

Lol, he seems to start to use the arguments like "You even do not know
my elder brother/acquaintance from the street nearby who can easily
hit you down!"

So, here, I would like to thank everybody in this discussion who
helped me to understand the danger of systemd and note that it is
now became pointless to continue this discussion with this "unpayed
systemd promoter."

> > anyway it is possible to disable this
> > stuff in kernel and guess what will be done on my systems.
> 
> Good for you. Guess what will be done in mine?
> 
> >> > Looks broken. Broken by design. The worst form of broken.
> >>
> >> By your opinion, not others.
> >
> > That is not just an opinion. There is a science and experience
> > behind system's design.
> 
> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
> or Keith Packard of X.org fame? None of them works for Red Hat; both
> of them know more about Unix and Linux than you and me together, and
> both of them promote systemd.

Aha! How could you even doubt my understanding the words of these prophets! :-)
 
> I mean, I myself know a thing or two about computing and Linux, and I
> promote systemd (and nobody pays me, BTW), but obviously you don't
> need to believe in my credentials.

I have said you, he is just an unpayed fanatic systemd promoter!  
 
> And, no offense, but I will always give more weight to the words of
> Greg Kroah-Hartman or Keith Packard (to name only two), instead of a
> random user in gentoo-user.
> 
> There are knowledgeable people who are against systemd. But usually
> they don't give *technical* sound reasons.
> 
> > And all that science was ignored during systemd
> > architecture process if there was any at all.
> 
> You should read systemd-devel and Lennart's blog posts

And A Holy Words of our Mighty God!

> before saying something like that. I did.
> 
> Regards

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 17/02/2014 17:29, Stroller wrote:
>>
>> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>> ...
>>> Whatever problems Red Hat are trying to solve in the Red Hat space are
>>> problems that do not affect me, so I do not need Red Hat's solution. As
>>> for Gnome, I have yet to see a valid reason why Gnome *must* use
>>> systemd; that is simply not true at all.
>>
>> I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter).
>
> That was the classic rationale for "no separate /usr without an initrd"
> in udev - the claimed need to have any arbitrary runnable code available
> to be run before the entire system is up and running.
>
> Red Hat's reasons for pushing systemd are more fuzzy and nothing I've
> read so far tells me we have the full picture. Two things seem highly
> plausible:
>
> 1. An init system that can use modern features of the Linux kernel (most
> often Linux-only at this point) like cgroups
> 2. Extremely fast boot times to spin up virtual machines in a fraction
> of the time it currently takes.
>
> #1 may or may not be desirable, I honestly don't know. What I have seen
> is a lot of theory and not much reproducable fact.

init scripts, in general, are ad-hoc, quirky, and incomplete
implementations of service supervision in bash. They're reliable so
long as the daemon can be relied on to advertise one or all of its
processes in a pid file. Thing is, there are way too many different
possible setups for services for that to be the case. In the average
case watching a PID file works. And since most people use "average
software", most people don't care. That's ok.

Thing is an init isn't just for "most people". It's for "all people".
It should be reliable for all services.

I used to use cherokee. Fast, light, awesome, and with a web admin.
The init script always failed me. /etc/init.d/cherokee stop was not a
guaranteed stop to all forked cherokee processes - the parent pid
dies, but some forked process or something, usually related to
rrdtool, doesn't. Or the parent does exit and erases the pid file but
it returns control immediately and its not yet done exiting. Something
like that or other. Point is, I've several times had to ps aux|grep
... kill; zap; start - on production servers.

Was it cherokee's fault? Maybe. But the init script should have told
me that. Or even better, the init script should have done its job and
terminted the processes. See, pid files are just a proxy, they don't
work for all services and all setups. Maybe a process crashes before
it kills its forks. Maybe the server has a restart feature that fails
to write the pid file because the init script created it as root but
the daemon relinquished privileges. Maybe there's a bug somewhere.
Maybe the pid file gets overwritten accidentally. Maybe the pid file
is stale because of a power failure. Point is you don't know until the
service restart which should "just take a sec" costs you maybe an hour
or two in billable time.

With supervised cgroups that's not a problem. Because all process
forks are grouped together, it doesn't matter if there's a pid file or
not. When its kill time, the daemon and all forks and children go
down. Because they're dynamically created on start, they don't get
stale or point to the wrong process. Sounds to me like the right tool
for the job.

The init script introduces a point of fragility and brittleness into
the system making it harder to debug, all to implement service
supervision. If you look at the upstream docs of your daemon, it'll
probably just tell you to run /usr/sbin/somethingd, maybe with a -d
argument, to find out why it isn't starting. Cue the init script now
always failing because you just created a bunch of files as the root
user. Bit me in the back a few times with mysqld. Oh, I'm supposed to
read the whole init script to determine all environment variables,
settings, and switches the system uses to start a daemon, right? Good
luck grepping. Because from a unit file, I can tell the command to run
in a single glance.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com> wrote:
[ snip ]
> How can you be sure if something is "large enough" if, as you say below,
> you do not care about probabilities?

By writing correct code?

>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>> > about 13 000 lines, systemd — about 200 000 lines.
>>
>> If you take into account the thousands of shell code that SysV and
>> OpenRC need to fill the functionality of systemd, they use even more.
>>
>> Also, again, systemd have a lot of little binaries, many of them
>> optional. The LOC of PID 1 is actually closer to SysV (although still
>> bigger).
>>
>> > Even assuming
>> > systemd code is as mature as sysvinit or openrc (though I doubt
>> > this) you can calculate probabilities of segfaults yourself easily.
>>
>> I don't care about probabilities;
>
> If you do not care (= do not now anything) about probabilities
> (and mathematics, in general), you just unable to understand
> that debugging a program with 200K lines of code take
>
> 200000!/(10000!)^20
>
> more time than debugging of 20 different programs with 10K lines of
> code. You can try to calculate that number yourself but I quite sure
> that if the latter can take, say, 20 days, the former can take
> millions of years.
>
> It is all the probability! Or, to be more precise, combinatorics.

My PhD thesis (which I will defend in a few weeks) is in computer
science, specifically computational geometry and combinatorics.

But hey, thanks for the lesson.

>> I care about facts: FACT, I've been using systemd since 2010,
>> in several machines, and I haven't had a single segfault.
>
> Have you ever tried forex? If yes, you should have been warned
> that "no past performance guarantee the future one."

I never said that. I trust the quality of the code, measured by my own
judgment and bug reports, etc. Not past performance.

And even if a bug goes by, then what? The world will end?

No, the bug will be reported, and fixed. And life will go on.

> And if you do not believe that (and do not care about probability
> and all the stuff like that), you should visit any of the forex forums
> where you will be suggested a magical money winning strategy that, in
> the past, behaved very well and earned 200 or even 500% a month.

Thanks for the tip, but I have never understood the people that
believes economics is closer to mathematics than sociology.

>> FACT: almost no bug report in systemd involves a
>> segfault in PID 1.
>>
>> >> >> All of them are different tools providing one capability to
>> >> >> systemd as a whole. So systemd is a collection of tools, where
>> >> >> each one does one thing, and it does it well.
>> >> >>
>> >> >> By your definition, systemd perfectly follows "the unix way".
>> >> >>
>> >> >
>> >> > no, it isn't.
>> >> >
>> >> > How are those binaries talk to each other?
>> >>
>> >> dbus, which is about to be integrated into the kernel with kdbus.
>> >
>> > And this is a very, very bad idea. Looks like you don't know matter
>> > at all: to begin with kdbus protocol is NOT compatible dbus and
>> > special converter daemon will be needed to enable dbus to talk to
>> > kdbus.
>>
>> kdbus uses a different wire protocol than dbus; but for clients that
>> doesn't matter; libsystemd-dbus will offer a compatibility layer (talk
>> about "standard" and "replaceable"), so if your application uses dbus
>> today, it will work with kdbus.
>>
>> Of course, new applications will take advantage of the new features
>> of kdbus.
>>
>> > The
>> > whole kdbus technology is very questionable itself (and was
>> > forcefully pushed by RH devs),
>>
>> Sorry, but it's you who doesn't know the matter at hand: kdbus was
>> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
>> works for the Linux Foundation.
>
> Lol, he seems to start to use the arguments like "You even do not know
> my elder brother/acquaintance from the street nearby who can easily
> hit you down!"

If you don't think Greg's words have any weight in a Linux-related
technical discussion, then I'm afraid we will need to agree to
disagree on any technical subject.

> So, here, I would like to thank everybody in this discussion who
> helped me to understand the danger of systemd and note that it is
> now became pointless to continue this discussion with this "unpayed
> systemd promoter."

Getting personal, are we?

>> > anyway it is possible to disable this
>> > stuff in kernel and guess what will be done on my systems.
>>
>> Good for you. Guess what will be done in mine?
>>
>> >> > Looks broken. Broken by design. The worst form of broken.
>> >>
>> >> By your opinion, not others.
>> >
>> > That is not just an opinion. There is a science and experience
>> > behind system's design.
>>
>> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
>> or Keith Packard of X.org fame? None of them works for Red Hat; both
>> of them know more about Unix and Linux than you and me together, and
>> both of them promote systemd.
>
> Aha! How could you even doubt my understanding the words of these prophets! :-)

They, contrary to you, actually give technical arguments instead of
splutter some nonsense about combinatorics that has nothing to do with
the subject at hand.

>> I mean, I myself know a thing or two about computing and Linux, and I
>> promote systemd (and nobody pays me, BTW), but obviously you don't
>> need to believe in my credentials.
>
> I have said you, he is just an unpayed fanatic systemd promoter!

OK, that's it; I actually thought for a moment that you wanted to have
a civil, intelligent and technical oriented conversation. I now see
you don't.

>> And, no offense, but I will always give more weight to the words of
>> Greg Kroah-Hartman or Keith Packard (to name only two), instead of a
>> random user in gentoo-user.
>>
>> There are knowledgeable people who are against systemd. But usually
>> they don't give *technical* sound reasons.
>>
>> > And all that science was ignored during systemd
>> > architecture process if there was any at all.
>>
>> You should read systemd-devel and Lennart's blog posts
>
> And A Holy Words of our Mighty God!

And that confirms it. Goodbye; I'm done with you in this thread.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 17/02/14, Canek Peláez Valdés wrote:

> It depends; right now you can't switch back and forth between OpenRC
> and systemd without reemerging some stuff. 

Interesting. Didn't know that. What packages need to be recompiled?

BTW, respect for your patience in this thread!

-- 
Nicolas Sebrecht

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 18/02/2014 05:46, Mark David Dumlao wrote:
> On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> > On 17/02/2014 17:29, Stroller wrote:
>>> >>
>>> >> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>> >>> ...
>>>> >>> Whatever problems Red Hat are trying to solve in the Red Hat space are
>>>> >>> problems that do not affect me, so I do not need Red Hat's solution. As
>>>> >>> for Gnome, I have yet to see a valid reason why Gnome *must* use
>>>> >>> systemd; that is simply not true at all.
>>> >>
>>> >> I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter).
>> >
>> > That was the classic rationale for "no separate /usr without an initrd"
>> > in udev - the claimed need to have any arbitrary runnable code available
>> > to be run before the entire system is up and running.
>> >
>> > Red Hat's reasons for pushing systemd are more fuzzy and nothing I've
>> > read so far tells me we have the full picture. Two things seem highly
>> > plausible:
>> >
>> > 1. An init system that can use modern features of the Linux kernel (most
>> > often Linux-only at this point) like cgroups
>> > 2. Extremely fast boot times to spin up virtual machines in a fraction
>> > of the time it currently takes.
>> >
>> > #1 may or may not be desirable, I honestly don't know. What I have seen
>> > is a lot of theory and not much reproducable fact.
> init scripts, in general, are ad-hoc, quirky, and incomplete
> implementations of service supervision in bash. They're reliable so
> long as the daemon can be relied on to advertise one or all of its
> processes in a pid file. Thing is, there are way too many different
> possible setups for services for that to be the case. In the average
> case watching a PID file works. And since most people use "average
> software", most people don't care. That's ok.
> 
> Thing is an init isn't just for "most people". It's for "all people".
> It should be reliable for all services.
> 
> I used to use cherokee. Fast, light, awesome, and with a web admin.
> The init script always failed me. /etc/init.d/cherokee stop was not a
> guaranteed stop to all forked cherokee processes - the parent pid
> dies, but some forked process or something, usually related to
> rrdtool, doesn't. Or the parent does exit and erases the pid file but
> it returns control immediately and its not yet done exiting. Something
> like that or other. Point is, I've several times had to ps aux|grep
> ... kill; zap; start - on production servers.


Valid point. Other than vixie-cron (damn thing just never seems to die
properly on any platform so restarts always fail) I don't really run
into these issues

What I do run into is daemons that drop privs on start up, like
tac_plus. Unwary new sysadmins always try start/stop it as root, causing
an unholy mess. Root the owns the log and pid files, when tac_plus drops
privs it can't record it's state so continues to service requests but
fails to log any of them. For an auth daemon, that's a serious issue.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
> On 18/02/2014 05:46, Mark David Dumlao wrote:
>> I used to use cherokee. Fast, light, awesome, and with a web admin.
>> The init script always failed me. /etc/init.d/cherokee stop was not a
>> guaranteed stop to all forked cherokee processes - the parent pid
>> dies, but some forked process or something, usually related to
>> rrdtool, doesn't. Or the parent does exit and erases the pid file but
>> it returns control immediately and its not yet done exiting. Something
>> like that or other. Point is, I've several times had to ps aux|grep
>> ... kill; zap; start - on production servers.
>
>
> Valid point. Other than vixie-cron (damn thing just never seems to die
> properly on any platform so restarts always fail) I don't really run
> into these issues

Interesting, I have never had issues with restarting vixie-cron using the
supplied init-scripts.

> What I do run into is daemons that drop privs on start up, like
> tac_plus. Unwary new sysadmins always try start/stop it as root, causing
> an unholy mess. Root the owns the log and pid files, when tac_plus drops
> privs it can't record it's state so continues to service requests but
> fails to log any of them. For an auth daemon, that's a serious issue.

Shouldn't sysadmins use the init-scripts for that?
If done correctly, permissions should not be an issue.

Restarting services without keeping file ownership into account will
always cause issues. Regardless of the init-system used.

And tac_plus not checking if it is allowed to write to the log during the
initialization phase should be considered a bug.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote:
> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> <volkerarmin@googlemail.com> wrote:
>> oh? I can pipe that output into cat or any any daemon I like? Doesn't
>> look like so.
>
> But it does, you can "cat" with journalctl; it's one of its output
> options:
>
>        -o, --output=
>            cat
>                generates a very terse output only showing the actual
> message of each journal entry with no meta data, not even a timestamp.

As I do not have systemd installed on any machine, I can't check the
man-pages.
But, if that is the only method to get parseable text from journalctl,
then that is less then useless.
I would expect an export option providing the same detail level as I
currently find in /var/log/messages.
A timestamp is a minimum required for logging system output.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 18/02/2014 11:52, J. Roeleveld wrote:
> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>> On 18/02/2014 05:46, Mark David Dumlao wrote:
>>> I used to use cherokee. Fast, light, awesome, and with a web admin.
>>> The init script always failed me. /etc/init.d/cherokee stop was not a
>>> guaranteed stop to all forked cherokee processes - the parent pid
>>> dies, but some forked process or something, usually related to
>>> rrdtool, doesn't. Or the parent does exit and erases the pid file but
>>> it returns control immediately and its not yet done exiting. Something
>>> like that or other. Point is, I've several times had to ps aux|grep
>>> ... kill; zap; start - on production servers.
>>
>>
>> Valid point. Other than vixie-cron (damn thing just never seems to die
>> properly on any platform so restarts always fail) I don't really run
>> into these issues
> 
> Interesting, I have never had issues with restarting vixie-cron using the
> supplied init-scripts.
> 
>> What I do run into is daemons that drop privs on start up, like
>> tac_plus. Unwary new sysadmins always try start/stop it as root, causing
>> an unholy mess. Root the owns the log and pid files, when tac_plus drops
>> privs it can't record it's state so continues to service requests but
>> fails to log any of them. For an auth daemon, that's a serious issue.
> 
> Shouldn't sysadmins use the init-scripts for that?
> If done correctly, permissions should not be an issue.

It's a little more complex than just that. It's an auth service and user
are frequently added, removed and modified. The daemon does syntax
checking on it's config file at startup or after being HUP'ed but that
only finds static errors. It catches things like adding people to a grop
instead of to a group, but misses dynamic mistakes like adding users to
groups that don't exist.

It's exactly analogous to compile-time vs runtime errors, compilers
can't catch the latter.

Despite this all being run out of cron with wrapper scripts to check
validity, automated additions and safety checks between all three
daemons, plus being fully documented on the internal wiki and in bold
blinking red caps in the login motd, people still find ways to do stuff
things in an attempt to fix it.

The daemon also tries to log these errors, by writing to a log file it
has no write permissions on.

There is nothing I can do about the quality of sysadmins, I have no
input into the HR process and damagement think cheaper is always better,
including skills. What I can do, is find ways to make the software more
resistant to errors than it already is.



> 
> Restarting services without keeping file ownership into account will
> always cause issues. Regardless of the init-system used.
> 
> And tac_plus not checking if it is allowed to write to the log during the
> initialization phase should be considered a bug.
> 
> --
> Joost
> 
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4675 bytes --]

On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote:
> > How Integrated? The TCP/IP stack *is* integrated. But it is *protocol*
> > integration, *standards* integration not *software* integration. You do want
> > tight integration where it just can't work otherwise, but the design of Unix
> > provides (well, again repeating this), and almost any robust design should
> > provide, the ignorance of one abstraction level about another. Why HAL? Why
> > udev? Why drivers as modules? Why not just go and integrate all stuff into
> > the kernel, well (again!) like MS do, and don't please say I compare wrong
> > things just because MS is not OSS.
> 
> You make a wrong comparison, because MS is not free (libre) software.
> With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we
> have been able to try new technologies (and see that some of them
> fail, like HAL [yuck!]), because we have the source.

But the comparison is quite right. When one have to deal with software
lock-in, this means that one have to fork a huge stack of software
which is theoretically doable (because software is free), but is
impractical unless one owns a corporation with large number of full
time paid developers. The same way one in theory can change everything
in MS by changing assembler code of their software. Well, this will
require some time, but asm is nothing more than low-level programming
language, thus formally one have "the sources".

The key feature here is deliberate and malicious lock-in: as long as
software enforces one, it is non-free in practical terms.

> As you said, you can replace the whole of Linux if you so desire (and
> have the technical ability).
> 
> You will never be able to do that with any MS software, and so the
> comparison makes no sense.

Hey, but people are already doing this! Google for ReactOS or Wine.

> The thing (and that's also my point), apparently *most* of the people
> willing and able to create cool software have decided that systemd is
> the way to go. And, even if you want to attribute that to a simple
> monetary issue, most of them do it *happily* because many things are
> just easier to do with systemd.

Most people should never care what init system is in charge while
writing end-user software. If software (e.g. some daemon) depends on
specific init system, it is broken by design.
 
> > They'll be able to
> > stuff everything into it, making effectively a thing in itself which will
> > dictate you where to go and what to do, just because you're not technically
> > competent enough to deal with it -- hence more support calls and more $ etc
> > etc.
> 
> Oh, but nobody will be able to do that to me. I know how to write
> code. I'm willing (and I believe able) to write and/or modify software
> if I don't like how it does things. I've done it before; I could do it
> again.

Even if you have superior and outstanding programming skills I doubt
you have time and resources to rewrite the whole software stack (e.g.
systemd and everything depending on it) yourself.

> >> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
> >> it would happen.
> >>
> >> But don't complain if no one does, and it doesn't.
> >
> >
> > That's your point -- and mine. We aren't complaining -- we want to prevent
> > this.
> 
> Prevent what? People writing new software that offers cool features,
> and therefore distros are using them?

Prevent loosing our freedom in practical sense: while the software
will be still free in FSF license terms, it will be so locked onto
itself that it will be eventually impossible for anyone besides large
corporations to replace it. Thus in the end we'll be dictated what to
do and how to do.

> > The forward-looking people must unite, it may sound ridiculous,
> > against systemd
> 
> You cannot stop people for writing new cool stuff, nor distros for
> wanting to using them. You CAN write your own cool stuff, and
> convincing people that is better than the alternative.

And you can't force people to use your cool stuff because you're
assuming it is cool. That's called freedom, freedom of choice. That
is what I love Gentoo for. That's why I support systemd
profile propose. That's why I will do my best to protect this freedom
in our community.

> > You know what it is: everything's free but nothing to choose from. We had it
> > before, it's called communism. Maybe it is not that bad but we don't want it
> > anymore.
> 
> (Really? A cold war reference?)

Yes, we have a software^Wcorporation war right upon us.
 
Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-17 3:17 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> OK, my choice of words was not appropriate. I mean that not every
> kernel dev is happy that kdbus is in the kernel now.

Noted...

Also, please don't CC me, I'm on the list...

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld <joost@antarean.org> wrote:
> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>> On 18/02/2014 05:46, Mark David Dumlao wrote:
>>> I used to use cherokee. Fast, light, awesome, and with a web admin.
>>> The init script always failed me. /etc/init.d/cherokee stop was not a
>>> guaranteed stop to all forked cherokee processes - the parent pid
>>> dies, but some forked process or something, usually related to
>>> rrdtool, doesn't. Or the parent does exit and erases the pid file but
>>> it returns control immediately and its not yet done exiting. Something
>>> like that or other. Point is, I've several times had to ps aux|grep
>>> ... kill; zap; start - on production servers.
>>
>>
>> Valid point. Other than vixie-cron (damn thing just never seems to die
>> properly on any platform so restarts always fail) I don't really run
>> into these issues
>
> Interesting, I have never had issues with restarting vixie-cron using the
> supplied init-scripts.
>
>> What I do run into is daemons that drop privs on start up, like
>> tac_plus. Unwary new sysadmins always try start/stop it as root, causing
>> an unholy mess. Root the owns the log and pid files, when tac_plus drops
>> privs it can't record it's state so continues to service requests but
>> fails to log any of them. For an auth daemon, that's a serious issue.
>
> Shouldn't sysadmins use the init-scripts for that?
> If done correctly, permissions should not be an issue.
>
> Restarting services without keeping file ownership into account will
> always cause issues. Regardless of the init-system used.
>

That's just the thing though. As a sysadmin, how do you debug a service
that isn't starting to begin with? Let's say your new to the service. You're
not even sure if you got the config right the first time around. Or maybe
you're adjusting a setting somewhere, and you're confused why it
isn't taking effect.

All the /upstream documentation/, all the /man pages/, all the /usr/share/doc
stuff will tell you to start it _raw_. The init script obscures the
starting options,
environment variables, and sometimes even the running user from you. What are
you gonna do, play a human shell script parser? Nobody's perfect, do it
enough times and you're going to casually gloss over the line where
--safe-mode is appended to the string depending on the phase of
the moon...

If you're lucky, you've never had to start an unfamiliar service, or debug
someone else's unfamiliar config under time pressure...

-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 12:54, Mark David Dumlao wrote:
> On Tue, Feb 18, 2014 at 5:52 PM, J. Roeleveld <joost@antarean.org> wrote:
>> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>>> On 18/02/2014 05:46, Mark David Dumlao wrote:
>>>> I used to use cherokee. Fast, light, awesome, and with a web admin.
>>>> The init script always failed me. /etc/init.d/cherokee stop was not a
>>>> guaranteed stop to all forked cherokee processes - the parent pid
>>>> dies, but some forked process or something, usually related to
>>>> rrdtool, doesn't. Or the parent does exit and erases the pid file but
>>>> it returns control immediately and its not yet done exiting. Something
>>>> like that or other. Point is, I've several times had to ps aux|grep
>>>> ... kill; zap; start - on production servers.
>>>
>>>
>>> Valid point. Other than vixie-cron (damn thing just never seems to die
>>> properly on any platform so restarts always fail) I don't really run
>>> into these issues
>>
>> Interesting, I have never had issues with restarting vixie-cron using
>> the
>> supplied init-scripts.
>>
>>> What I do run into is daemons that drop privs on start up, like
>>> tac_plus. Unwary new sysadmins always try start/stop it as root,
>>> causing
>>> an unholy mess. Root the owns the log and pid files, when tac_plus
>>> drops
>>> privs it can't record it's state so continues to service requests but
>>> fails to log any of them. For an auth daemon, that's a serious issue.
>>
>> Shouldn't sysadmins use the init-scripts for that?
>> If done correctly, permissions should not be an issue.
>>
>> Restarting services without keeping file ownership into account will
>> always cause issues. Regardless of the init-system used.
>>
>
> That's just the thing though. As a sysadmin, how do you debug a service
> that isn't starting to begin with?

This isn't what Alan was talking about.
He was talking about restarting an existing, working service.

> Let's say your new to the service.
> You're
> not even sure if you got the config right the first time around. Or maybe
> you're adjusting a setting somewhere, and you're confused why it
> isn't taking effect.

In an environment where Alan works, I wouldn't be the only person around.
There should be someone on call who knows.

> All the /upstream documentation/, all the /man pages/, all the
> /usr/share/doc
> stuff will tell you to start it _raw_. The init script obscures the
> starting options,
> environment variables, and sometimes even the running user from you. What
> are
> you gonna do, play a human shell script parser? Nobody's perfect, do it
> enough times and you're going to casually gloss over the line where
> --safe-mode is appended to the string depending on the phase of
> the moon...
>
> If you're lucky, you've never had to start an unfamiliar service, or debug
> someone else's unfamiliar config under time pressure...

I have been on both ends of this.

I have multiple times been in a situation where I was under time-pressure
to get services running again on unfamiliar systems. Talking untrained
admins through the process by phone-communication only.
It is not easy, but by staying calm and focused, mistakes are avoided.
Also, in my experience, a calm systematic approach is usually faster then
the cowboy-method of trying everything I can find on Google.

I have also, too often, had to clean up the mess caused by these cowboy
tactics.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 12:17, Alan McKinnon wrote:
> On 18/02/2014 11:52, J. Roeleveld wrote:
>> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>>> What I do run into is daemons that drop privs on start up, like
>>> tac_plus. Unwary new sysadmins always try start/stop it as root,
>>> causing
>>> an unholy mess. Root the owns the log and pid files, when tac_plus
>>> drops
>>> privs it can't record it's state so continues to service requests but
>>> fails to log any of them. For an auth daemon, that's a serious issue.
>>
>> Shouldn't sysadmins use the init-scripts for that?
>> If done correctly, permissions should not be an issue.
>
> It's a little more complex than just that. It's an auth service and user
> are frequently added, removed and modified. The daemon does syntax
> checking on it's config file at startup or after being HUP'ed but that
> only finds static errors. It catches things like adding people to a grop
> instead of to a group, but misses dynamic mistakes like adding users to
> groups that don't exist.

The auth-service gets the current state from a static file that is only
read upon service-start?

> It's exactly analogous to compile-time vs runtime errors, compilers
> can't catch the latter.
>
> Despite this all being run out of cron with wrapper scripts to check
> validity, automated additions and safety checks between all three
> daemons, plus being fully documented on the internal wiki and in bold
> blinking red caps in the login motd, people still find ways to do stuff
> things in an attempt to fix it.

(OT: Does the bold blinking red caps work on all terminals? :) )

> The daemon also tries to log these errors, by writing to a log file it
> has no write permissions on.

"setuid" on the group with group-write in the umask not an option?

> There is nothing I can do about the quality of sysadmins, I have no
> input into the HR process and damagement think cheaper is always better,
> including skills. What I can do, is find ways to make the software more
> resistant to errors than it already is.

And only grant access permissions to these rookies once they have proven
they understand rule #1: If In Doubt, Call Someone Who Knows!

But yes, I fully understand the methods of HR and Damagement.
It is a financial mistake and risk not to include technical expertise
checks in the recruitement fase for technical positions.

How much does it cost the company each time this goes wrong and someone
like you has to come online to fix the issue?
That is what Damagement needs to understand.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Mon, 17 Feb 2014 23:30:42 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com> wrote:
> [ snip ]
> > How can you be sure if something is "large enough" if, as you say
> > below, you do not care about probabilities?
> 
> By writing correct code?

No, by arguing that fixing bugs in a 200K line program is as easy as
fixing a bug in 20 10K line programs. It is just not true, just the
opposite. 

> >> > SysVinit code size is about 10 000 lines of code, OpenRC contains
> >> > about 13 000 lines, systemd — about 200 000 lines.
> >>
> >> If you take into account the thousands of shell code that SysV and
> >> OpenRC need to fill the functionality of systemd, they use even
> >> more.
> >>
> >> Also, again, systemd have a lot of little binaries, many of them
> >> optional. The LOC of PID 1 is actually closer to SysV (although
> >> still bigger).
> >>
> >> > Even assuming
> >> > systemd code is as mature as sysvinit or openrc (though I doubt
> >> > this) you can calculate probabilities of segfaults yourself
> >> > easily.
> >>
> >> I don't care about probabilities;
> >
> > If you do not care (= do not now anything) about probabilities
> > (and mathematics, in general), you just unable to understand
> > that debugging a program with 200K lines of code take
> >
> > 200000!/(10000!)^20
> >
> > more time than debugging of 20 different programs with 10K lines of
> > code. You can try to calculate that number yourself but I quite sure
> > that if the latter can take, say, 20 days, the former can take
> > millions of years.
> >
> > It is all the probability! Or, to be more precise, combinatorics.
> 
> My PhD thesis (which I will defend in a few weeks) is in computer
> science, specifically computational geometry and combinatorics.

It is even more shameful for you to not understand such a simple facts
from elementary probability theory (which is mostly based on
combinatorics).

And, believe me, here, in this mailing list, there are a lot people
that have there PhD defended a long time ago. However, they do not
thing it is appropriate to use such facts in their arguments about
merits or "dismerits" of one or the other approach to computer
programming.   

> But hey, thanks for the lesson.

Not at all.

> >> I care about facts: FACT, I've been using systemd since 2010,
> >> in several machines, and I haven't had a single segfault.
> >
> > Have you ever tried forex? If yes, you should have been warned
> > that "no past performance guarantee the future one."
> 
> I never said that. I trust the quality of the code, measured by my own
> judgment and bug reports, etc. Not past performance.
> 
> And even if a bug goes by, then what? The world will end?
> 
> No, the bug will be reported, and fixed. And life will go on.
> 
> > And if you do not believe that (and do not care about probability
> > and all the stuff like that), you should visit any of the forex
> > forums where you will be suggested a magical money winning strategy
> > that, in the past, behaved very well and earned 200 or even 500% a
> > month.
> 
> Thanks for the tip, but I have never understood the people that
> believes economics is closer to mathematics than sociology.
> 
> >> FACT: almost no bug report in systemd involves a
> >> segfault in PID 1.
> >>
> >> >> >> All of them are different tools providing one capability to
> >> >> >> systemd as a whole. So systemd is a collection of tools,
> >> >> >> where each one does one thing, and it does it well.
> >> >> >>
> >> >> >> By your definition, systemd perfectly follows "the unix way".
> >> >> >>
> >> >> >
> >> >> > no, it isn't.
> >> >> >
> >> >> > How are those binaries talk to each other?
> >> >>
> >> >> dbus, which is about to be integrated into the kernel with
> >> >> kdbus.
> >> >
> >> > And this is a very, very bad idea. Looks like you don't know
> >> > matter at all: to begin with kdbus protocol is NOT compatible
> >> > dbus and special converter daemon will be needed to enable dbus
> >> > to talk to kdbus.
> >>
> >> kdbus uses a different wire protocol than dbus; but for clients
> >> that doesn't matter; libsystemd-dbus will offer a compatibility
> >> layer (talk about "standard" and "replaceable"), so if your
> >> application uses dbus today, it will work with kdbus.
> >>
> >> Of course, new applications will take advantage of the new features
> >> of kdbus.
> >>
> >> > The
> >> > whole kdbus technology is very questionable itself (and was
> >> > forcefully pushed by RH devs),
> >>
> >> Sorry, but it's you who doesn't know the matter at hand: kdbus was
> >> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
> >> works for the Linux Foundation.
> >
> > Lol, he seems to start to use the arguments like "You even do not
> > know my elder brother/acquaintance from the street nearby who can
> > easily hit you down!"
> 
> If you don't think Greg's words have any weight in a Linux-related
> technical discussion, then I'm afraid we will need to agree to
> disagree on any technical subject.
> 
> > So, here, I would like to thank everybody in this discussion who
> > helped me to understand the danger of systemd and note that it is
> > now became pointless to continue this discussion with this "unpayed
> > systemd promoter."
> 
> Getting personal, are we?

I am really sorry for getting personal here, but it was only because
your level of argumentation went far below any acceptable level and
it became absolutely clear that you continue to argue only because
you do not want to accept that you are wrong and, moreover, it already
looks like you are trying to sell to others the thing that they do not
want to buy. 

> >> > anyway it is possible to disable this
> >> > stuff in kernel and guess what will be done on my systems.
> >>
> >> Good for you. Guess what will be done in mine?
> >>
> >> >> > Looks broken. Broken by design. The worst form of broken.
> >> >>
> >> >> By your opinion, not others.
> >> >
> >> > That is not just an opinion. There is a science and experience
> >> > behind system's design.
> >>
> >> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right
> >> hand, or Keith Packard of X.org fame? None of them works for Red
> >> Hat; both of them know more about Unix and Linux than you and me
> >> together, and both of them promote systemd.
> >
> > Aha! How could you even doubt my understanding the words of these
> > prophets! :-)
> 
> They, contrary to you, actually give technical arguments instead of
> splutter some nonsense about combinatorics that has nothing to do with
> the subject at hand.
> 
> >> I mean, I myself know a thing or two about computing and Linux,
> >> and I promote systemd (and nobody pays me, BTW), but obviously you
> >> don't need to believe in my credentials.
> >
> > I have said you, he is just an unpayed fanatic systemd promoter!
> 
> OK, that's it; I actually thought for a moment that you wanted to have
> a civil, intelligent and technical oriented conversation. I now see
> you don't.

Once more, I am really sorry for getting personal here, but it was only
because your level of argumentation went far below any acceptable level
and it became absolutely clear that you continue to argue only because
you do not want to accept that you are wrong and, moreover, it already
looks like you are trying to sell to others the thing that they do not
want to buy.

> >> And, no offense, but I will always give more weight to the words of
> >> Greg Kroah-Hartman or Keith Packard (to name only two), instead of
> >> a random user in gentoo-user.
> >>
> >> There are knowledgeable people who are against systemd. But usually
> >> they don't give *technical* sound reasons.
> >>
> >> > And all that science was ignored during systemd
> >> > architecture process if there was any at all.
> >>
> >> You should read systemd-devel and Lennart's blog posts
> >
> > And A Holy Words of our Mighty God!
> 
> And that confirms it. Goodbye; I'm done with you in this thread.
> 
> Regards.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 2:19 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 17/02/14, Canek Peláez Valdés wrote:
>
>> It depends; right now you can't switch back and forth between OpenRC
>> and systemd without reemerging some stuff.
>
> Interesting. Didn't know that. What packages need to be recompiled?

Some packages need to be emerged with USE="-systemd" when going from
systemd to OpenRC, and with USE="systemd" the other way around.
Different code paths are selected in each case.

As I said before, the code paths could be chosen at run time, but I
don't think any upstream will accept patches supporting this, or think
that they are useful

> BTW, respect for your patience in this thread!

Thanks; I've been on the list since 2002, so I think I can say that
this thread has been actually pretty civil and technically oriented
(except for a couple of trolls).

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld <joost@antarean.org> wrote:
> On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote:
>> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
>> <volkerarmin@googlemail.com> wrote:
>>> oh? I can pipe that output into cat or any any daemon I like? Doesn't
>>> look like so.
>>
>> But it does, you can "cat" with journalctl; it's one of its output
>> options:
>>
>>        -o, --output=
>>            cat
>>                generates a very terse output only showing the actual
>> message of each journal entry with no meta data, not even a timestamp.
>
> As I do not have systemd installed on any machine, I can't check the
> man-pages.

They are online [1].

> But, if that is the only method to get parseable text from journalctl,
> then that is less then useless.

I only put that option as tongue-in-cheek, since someone complained
about not being able to "cat" the logs. Many more options are
available.

> I would expect an export option providing the same detail level as I
> currently find in /var/log/messages.
> A timestamp is a minimum required for logging system output.

Everybody agrees with that; that's why the journal supports a lot of
formatting options. From [2]:

       -o, --output=
           Controls the formatting of the journal entries that are
shown. Takes one of the following options:

           short
               is the default and generates an output that is mostly
identical to the formatting of classic syslog files, showing one line
per journal entry.

           short-iso
               is very similar, but shows ISO 8601 wallclock timestamps.

           short-precise
               is very similar, but shows timestamps with full
microsecond precision.

           short-monotonic
               is very similar, but shows monotonic timestamps instead
of wallclock timestamps.

           verbose
               shows the full-structured entry items with all fields.

           export
               serializes the journal into a binary (but mostly
text-based) stream suitable for backups and network transfer (see
Journal Export Format[1] for more information).

           json
               formats entries as JSON data structures, one per line
(see Journal JSON Format[2] for more information).

           json-pretty
               formats entries as JSON data structures, but formats
them in multiple lines in order to make them more readable for humans.

           json-sse
               formats entries as JSON data structures, but wraps them
in a format suitable for Server-Sent Events[3].

           cat
               generates a very terse output only showing the actual
message of each journal entry with no meta data, not even a timestamp.


So you can have the default; journalctl -b | head:

-- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18
08:28:44 CST. --
Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is
using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M).
Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is
using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M).
Feb 10 09:50:37 centurion systemd-journal[371]: Journal started
Feb 10 09:50:37 centurion systemd-modules-load[370]: Inserted module 'fuse'
Feb 10 09:50:37 centurion systemd[1]: Starting Swap.
Feb 10 09:50:37 centurion systemd[1]: Reached target Swap.
Feb 10 09:50:37 centurion systemd-modules-load[370]: Inserted module 'kvm_intel'
Feb 10 09:50:37 centurion systemd[1]: Starting Local File Systems.
Feb 10 09:50:37 centurion systemd-journal[371]: Missed 107 kernel messages

(The -b option shows the logs from the current boot; you can get the
previous one with -b -1, the one before with -b -2, etc.)

You can have short; journalctl -b -o short | head, which for the first
lines of my current boot look the same as the default. You can have
ISO timestamps; journalctl -b -o short-iso:

-- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18
08:31:54 CST. --
2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Runtime
journal is using 712.0K (max 198.0M, leaving 297.1M of free 1.9G,
current limit 198.0M).
2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Runtime
journal is using 716.0K (max 198.0M, leaving 297.1M of free 1.9G,
current limit 198.0M).
2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Journal started
2014-02-10T09:50:37-0600 centurion systemd-modules-load[370]: Inserted
module 'fuse'
2014-02-10T09:50:37-0600 centurion systemd[1]: Starting Swap.
2014-02-10T09:50:37-0600 centurion systemd[1]: Reached target Swap.
2014-02-10T09:50:37-0600 centurion systemd-modules-load[370]: Inserted
module 'kvm_intel'
2014-02-10T09:50:37-0600 centurion systemd[1]: Starting Local File Systems.
2014-02-10T09:50:37-0600 centurion systemd-journal[371]: Missed 107
kernel messages

You can have nanosecond precision; journalctl -b -o short-precise | head:

-- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18
08:31:54 CST. --
Feb 10 09:50:37.689600 centurion systemd-journal[371]: Runtime journal
is using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current
limit 198.0M).
Feb 10 09:50:37.689910 centurion systemd-journal[371]: Runtime journal
is using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current
limit 198.0M).
Feb 10 09:50:37.690139 centurion systemd-journal[371]: Journal started
Feb 10 09:50:37.690184 centurion systemd-modules-load[370]: Inserted
module 'fuse'
Feb 10 09:50:37.689866 centurion systemd[1]: Starting Swap.
Feb 10 09:50:37.689902 centurion systemd[1]: Reached target Swap.
Feb 10 09:50:37.689982 centurion systemd-modules-load[370]: Inserted
module 'kvm_intel'
Feb 10 09:50:37.690419 centurion systemd[1]: Starting Local File Systems.
Feb 10 09:50:37.692022 centurion systemd-journal[371]: Missed 107
kernel messages

You can have monotonic timestamps; journalctl -b -o short-monotonic | head:

-- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18
08:32:44 CST. --
[    0.568295] centurion systemd-journal[371]: Runtime journal is
using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M).
[    0.568605] centurion systemd-journal[371]: Runtime journal is
using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M).
[    0.568834] centurion systemd-journal[371]: Journal started
[    0.569202] centurion systemd-modules-load[370]: Inserted module 'fuse'
[    0.569530] centurion systemd[1]: Starting Swap.
[    0.569823] centurion systemd[1]: Reached target Swap.
[    0.570157] centurion systemd-modules-load[370]: Inserted module 'kvm_intel'
[    0.570452] centurion systemd[1]: Starting Local File Systems.
[    0.570718] centurion systemd-journal[371]: Missed 107 kernel messages

You can get it formatted with JSON; journalctl -b -o json | head -n 3:

{ "__CURSOR" : "s=12a9a4b1107f4a1e8219c6f392b59998;i=577;b=85b3bd9a292b40da80a73aac41f06840;m=8abe7;t=4f20f4d08b300;x=ac5d8ecfe215e10f",
"__REALTIME_TIMESTAMP" : "1392047437689600", "__MONOTONIC_TIMESTAMP" :
"568295", "_BOOT_ID" : "85b3bd9a292b40da80a73aac41f06840", "PRIORITY"
: "6", "_TRANSPORT" : "driver", "MESSAGE" : "Runtime journal is using
712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M).", "MESSAGE_ID" : "ec387f577b844b8fa948f33cad9a75e6", "_PID" :
"371", "_UID" : "0", "_GID" : "0", "_COMM" : "systemd-journal", "_EXE"
: "/usr/lib64/systemd/systemd-journald", "_CMDLINE" :
"/usr/lib/systemd/systemd-journald", "_CAP_EFFECTIVE" : "4402800cf",
"_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service",
"_SYSTEMD_UNIT" : "systemd-journald.service", "_SYSTEMD_SLICE" :
"system.slice", "_MACHINE_ID" : "386846e50fae217775d8d80045a18054",
"_HOSTNAME" : "centurion" }
{ "__CURSOR" : "s=12a9a4b1107f4a1e8219c6f392b59998;i=578;b=85b3bd9a292b40da80a73aac41f06840;m=8ad1d;t=4f20f4d08b436;x=5d13a456b0fc099a",
"__REALTIME_TIMESTAMP" : "1392047437689910", "__MONOTONIC_TIMESTAMP" :
"568605", "_BOOT_ID" : "85b3bd9a292b40da80a73aac41f06840", "PRIORITY"
: "6", "_TRANSPORT" : "driver", "MESSAGE_ID" :
"ec387f577b844b8fa948f33cad9a75e6", "_PID" : "371", "_UID" : "0",
"_GID" : "0", "_COMM" : "systemd-journal", "_EXE" :
"/usr/lib64/systemd/systemd-journald", "_CMDLINE" :
"/usr/lib/systemd/systemd-journald", "_CAP_EFFECTIVE" : "4402800cf",
"_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service",
"_SYSTEMD_UNIT" : "systemd-journald.service", "_SYSTEMD_SLICE" :
"system.slice", "_MACHINE_ID" : "386846e50fae217775d8d80045a18054",
"_HOSTNAME" : "centurion", "MESSAGE" : "Runtime journal is using
716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
198.0M)." }
{ "__CURSOR" : "s=12a9a4b1107f4a1e8219c6f392b59998;i=579;b=85b3bd9a292b40da80a73aac41f06840;m=8ae02;t=4f20f4d08b51b;x=656aa8fa8583d9dd",
"__REALTIME_TIMESTAMP" : "1392047437690139", "__MONOTONIC_TIMESTAMP" :
"568834", "_BOOT_ID" : "85b3bd9a292b40da80a73aac41f06840", "PRIORITY"
: "6", "_TRANSPORT" : "driver", "_PID" : "371", "_UID" : "0", "_GID" :
"0", "_COMM" : "systemd-journal", "_EXE" :
"/usr/lib64/systemd/systemd-journald", "_CMDLINE" :
"/usr/lib/systemd/systemd-journald", "_CAP_EFFECTIVE" : "4402800cf",
"_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service",
"_SYSTEMD_UNIT" : "systemd-journald.service", "_SYSTEMD_SLICE" :
"system.slice", "_MACHINE_ID" : "386846e50fae217775d8d80045a18054",
"_HOSTNAME" : "centurion", "MESSAGE" : "Journal started", "MESSAGE_ID"
: "f77379a8490b408bbe5f6940505a777b" }

Or pretty JSON; journalctl -b -o json-pretty | head -n 22:

{
        "__CURSOR" :
"s=12a9a4b1107f4a1e8219c6f392b59998;i=577;b=85b3bd9a292b40da80a73aac41f06840;m=8abe7;t=4f20f4d08b300;x=ac5d8ecfe215e10f",
        "__REALTIME_TIMESTAMP" : "1392047437689600",
        "__MONOTONIC_TIMESTAMP" : "568295",
        "_BOOT_ID" : "85b3bd9a292b40da80a73aac41f06840",
        "PRIORITY" : "6",
        "_TRANSPORT" : "driver",
        "MESSAGE" : "Runtime journal is using 712.0K (max 198.0M,
leaving 297.1M of free 1.9G, current limit 198.0M).",
        "MESSAGE_ID" : "ec387f577b844b8fa948f33cad9a75e6",
        "_PID" : "371",
        "_UID" : "0",
        "_GID" : "0",
        "_COMM" : "systemd-journal",
        "_EXE" : "/usr/lib64/systemd/systemd-journald",
        "_CMDLINE" : "/usr/lib/systemd/systemd-journald",
        "_CAP_EFFECTIVE" : "4402800cf",
        "_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service",
        "_SYSTEMD_UNIT" : "systemd-journald.service",
        "_SYSTEMD_SLICE" : "system.slice",
        "_MACHINE_ID" : "386846e50fae217775d8d80045a18054",
        "_HOSTNAME" : "centurion"
}

See if you can easily do that with rsyslog or syslog-ng.

Regards.

[1] http://www.freedesktop.org/software/systemd/man/
[2] http://www.freedesktop.org/software/systemd/man/journalctl.html

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 5:35 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote:
>> > How Integrated? The TCP/IP stack *is* integrated. But it is *protocol*
>> > integration, *standards* integration not *software* integration. You do want
>> > tight integration where it just can't work otherwise, but the design of Unix
>> > provides (well, again repeating this), and almost any robust design should
>> > provide, the ignorance of one abstraction level about another. Why HAL? Why
>> > udev? Why drivers as modules? Why not just go and integrate all stuff into
>> > the kernel, well (again!) like MS do, and don't please say I compare wrong
>> > things just because MS is not OSS.
>>
>> You make a wrong comparison, because MS is not free (libre) software.
>> With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we
>> have been able to try new technologies (and see that some of them
>> fail, like HAL [yuck!]), because we have the source.
>
> But the comparison is quite right. When one have to deal with software
> lock-in, this means that one have to fork a huge stack of software
> which is theoretically doable (because software is free), but is
> impractical unless one owns a corporation with large number of full
> time paid developers. The same way one in theory can change everything
> in MS by changing assembler code of their software. Well, this will
> require some time, but asm is nothing more than low-level programming
> language, thus formally one have "the sources".

You cannot distribute changes that you do to proprietary disassembled
code. So again, the comparison makes no sense.

> The key feature here is deliberate and malicious lock-in: as long as
> software enforces one, it is non-free in practical terms.

We are running around in circles; I told you why is not a reasonable
comparison, and I failed to convince you. You told me that it's a
right comparison to make, and you failed to convince me. We could keep
beating a dead horse, but it's better if we agree to disagree on this
point.

(Which kinda makes the rest of the discussion moot, but whatever).

>> As you said, you can replace the whole of Linux if you so desire (and
>> have the technical ability).
>>
>> You will never be able to do that with any MS software, and so the
>> comparison makes no sense.
>
> Hey, but people are already doing this! Google for ReactOS or Wine.

I mentioned ReactOS in this thread; from [1]:

"If enough people, willing and able, want to do it, they will. Look at
ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD."

However, the ReactOS people aren't disassembling code; they are coding
a different (but compatible) implementation. Same goes with Wine.

And even if you say that disassembled code is the same as carefully
written code (which is not), we have comments inside the code [2], and
DCSV logs [3], and tons of documentation. With proprietary code we
don't; sometimes a little documentation for how to *use* the code, but
not how to *change* it or *understand* it.

>> The thing (and that's also my point), apparently *most* of the people
>> willing and able to create cool software have decided that systemd is
>> the way to go. And, even if you want to attribute that to a simple
>> monetary issue, most of them do it *happily* because many things are
>> just easier to do with systemd.
>
> Most people should never care what init system is in charge while
> writing end-user software. If software (e.g. some daemon) depends on
> specific init system, it is broken by design.

They don't care about the "init" system. They care about the
*features* systemd provides; logind, the journal, timedated,
hostnamed, etc.

Obviously systemd is much more than just an init system.

>> > They'll be able to
>> > stuff everything into it, making effectively a thing in itself which will
>> > dictate you where to go and what to do, just because you're not technically
>> > competent enough to deal with it -- hence more support calls and more $ etc
>> > etc.
>>
>> Oh, but nobody will be able to do that to me. I know how to write
>> code. I'm willing (and I believe able) to write and/or modify software
>> if I don't like how it does things. I've done it before; I could do it
>> again.
>
> Even if you have superior and outstanding programming skills I doubt
> you have time and resources to rewrite the whole software stack (e.g.
> systemd and everything depending on it) yourself.

As I said, that is moot since Linux+systemd+GNOME are taking Linux to
the place I always wanted it to be.

>> >> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE
>> >> it would happen.
>> >>
>> >> But don't complain if no one does, and it doesn't.
>> >
>> >
>> > That's your point -- and mine. We aren't complaining -- we want to prevent
>> > this.
>>
>> Prevent what? People writing new software that offers cool features,
>> and therefore distros are using them?
>
> Prevent loosing our freedom in practical sense: while the software
> will be still free in FSF license terms, it will be so locked onto
> itself that it will be eventually impossible for anyone besides large
> corporations to replace it. Thus in the end we'll be dictated what to
> do and how to do.

You will never loose your freedom in the most practical of senses: the
code is free.

>> > The forward-looking people must unite, it may sound ridiculous,
>> > against systemd
>>
>> You cannot stop people for writing new cool stuff, nor distros for
>> wanting to using them. You CAN write your own cool stuff, and
>> convincing people that is better than the alternative.
>
> And you can't force people to use your cool stuff because you're
> assuming it is cool.

Who is forcing you? If at some point in the future the Gentoo council
sets systemd as the default recommended init system for the
distribution, OpenRC will still be available.

Nobody is forcing no one to anything.

> That's called freedom, freedom of choice. That
> is what I love Gentoo for. That's why I support systemd
> profile propose.

Well, "support" is code, not words. This is not a democracy; the users
don't "vote" what they want.

If that's the option you prefer, help the devs achieve it.

> That's why I will do my best to protect this freedom
> in our community.

Do it with code, not arguing in a mailing list.

And I'm not talking about C; ebuilds, overlays, the profiles settings,
even documentation; anything that helps the distro go in the direction
you want it to go.

Again, arguing in the ML has no real impact in the distro.

>> > You know what it is: everything's free but nothing to choose from. We had it
>> > before, it's called communism. Maybe it is not that bad but we don't want it
>> > anymore.
>>
>> (Really? A cold war reference?)
>
> Yes, we have a software^Wcorporation war right upon us.

There is no war; we are all on the same side, the FLOSS side.

Regards.

[1] http://article.gmane.org/gmane.linux.gentoo.user/272617
[2] http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/sd-journal.c#n63
[3] http://cgit.freedesktop.org/systemd/systemd/log/
[4] http://www.freedesktop.org/wiki/Software/systemd/#manualsanddocumentationforusersandadministrators
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2523 bytes --]

On Tue, 18 Feb 2014 11:46:14 +0800 Mark David Dumlao wrote:
> init scripts, in general, are ad-hoc, quirky, and incomplete
> implementations of service supervision in bash. They're reliable so
> long as the daemon can be relied on to advertise one or all of its
> processes in a pid file. Thing is, there are way too many different
> possible setups for services for that to be the case. In the average
> case watching a PID file works. And since most people use "average
> software", most people don't care. That's ok.
> 
> Thing is an init isn't just for "most people". It's for "all people".
> It should be reliable for all services.
> 
> I used to use cherokee. Fast, light, awesome, and with a web admin.
> The init script always failed me. /etc/init.d/cherokee stop was not a
> guaranteed stop to all forked cherokee processes - the parent pid
> dies, but some forked process or something, usually related to
> rrdtool, doesn't. Or the parent does exit and erases the pid file but
> it returns control immediately and its not yet done exiting. Something
> like that or other. Point is, I've several times had to ps aux|grep
> ... kill; zap; start - on production servers.
> 
> Was it cherokee's fault? Maybe. But the init script should have told
> me that. Or even better, the init script should have done its job and
> terminted the processes. See, pid files are just a proxy, they don't
> work for all services and all setups. Maybe a process crashes before
> it kills its forks. Maybe the server has a restart feature that fails
> to write the pid file because the init script created it as root but
> the daemon relinquished privileges. Maybe there's a bug somewhere.
> Maybe the pid file gets overwritten accidentally. Maybe the pid file
> is stale because of a power failure. Point is you don't know until the
> service restart which should "just take a sec" costs you maybe an hour
> or two in billable time.
> 
> With supervised cgroups that's not a problem. Because all process
> forks are grouped together, it doesn't matter if there's a pid file or
> not. When its kill time, the daemon and all forks and children go
> down. Because they're dynamically created on start, they don't get
> stale or point to the wrong process. Sounds to me like the right tool
> for the job.

I agree with you. But openrc has cgroups support now for each
service started. Thus systemd is not the only solution solving
problem you described above.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]

On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés wrote:
[...]
> >> >>> Complexity means bugs.
> >> >> Bugs get reported, bugs get fixes. Life goes on.
> >>
> >> You didn't answered this, did you?
> >
> > Bugs are different.
> 
> Bugs are bugs, period. And they get reported and fixed.

Bugs are not equal. They differ in at least two dimensions:
significance depending on the component affected and severity of the
bug itself.

> > Bugs in the critical system components are
> > critical to the whole system.
> 
> Yeah, that's why we have unit testing and QA teams and stable and
> unstable releases, etc.

Every decent project has QA and unit tests one way or another. But
the larger project is, the more bugs it has. And I do not want bugs
in PID 1, that's why it should be small and sound, not bloated (even
with some components split as separate binaries) and broken by design.

> > If Libreoffice or browser
> > segfaults, some data may be lost and inconvenience created, but the
> > system will continue to run. If PID 1 segfaults — everything is
> > lost, you have a kernel panic.
> 
> And the world will end? The same happens if the kernel has an error.

Kernel has mature error correction infrastructure (Oops handling) and
much wider community.
 
> > That's why critical components should
> > be as simple and clean as possible.
> 
> Like the kernel? You call that "simple"?

Don't mix user space and kernel space, please. There are
more secure by design micro kernels out there (like Hurd), but
they're out of the scope of this discussion.

> I'm sorry, but you are (IMO) wrong: critical components should be
> thoroughly tested and debugged, and have integrated unit testing, and
> a large enough group of volunteers to test new releases before they go
> into the general public.

You're pointing to valid issues, but not to the whole picture.
Critical components should _start_ from good design, sound modular
architecture and _then_ with QA and testing. You're omitting the most
important stuff, though.

> > SysVinit code size is about 10 000 lines of code, OpenRC contains
> > about 13 000 lines, systemd — about 200 000 lines.
> 
> If you take into account the thousands of shell code that SysV and
> OpenRC need to fill the functionality of systemd, they use even more.

If that code will fail, this wouldn't be critical at system level.
Thus scope of fatal error is limited.

> > Even assuming
> > systemd code is as mature as sysvinit or openrc (though I doubt this)
> > you can calculate probabilities of segfaults yourself easily.
> 
> I don't care about probabilities; I care about facts: FACT, I've been
> using systemd since 2010, in several machines, and I haven't had a
> single segfault. FACT: almost no bug report in systemd involves a
> segfault in PID 1.

You need facts? Here is one for you (systemd-208):
http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg
 
> >> > Looks broken. Broken by design. The worst form of broken.
> >>
> >> By your opinion, not others.
> >
> > That is not just an opinion. There is a science and experience behind
> > system's design.
> 
> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
> or Keith Packard of X.org fame? None of them works for Red Hat; both
> of them know more about Unix and Linux than you and me together, and
> both of them promote systemd.

I respect Greg for most of his work, but this doesn't mean he is an
oracle we need to adhere to. But in FOSS reputation is not that
important, though clean technical reasons are.
 
> > And all that science was ignored during systemd
> > architecture process if there was any at all.
> 
> You should read systemd-devel and Lennart's blog posts before saying
> something like that. I did.

I read that blog. No valid reason were found (if we're comparing
systemd to what is outside of systemd's world, not only to bare
sysvinit). But what I found it that blog is a lack of thorough
project design (it looks like many components were added by the fly
without preliminary planning) and a lot of religious statements.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote:
> > I mean, I myself know a thing or two about computing and Linux, and I
> > promote systemd (and nobody pays me, BTW), but obviously you don't
> > need to believe in my credentials.
> 
> I have said you, he is just an unpayed fanatic systemd promoter!  

Frankly, I have doubts he is unpayed. Though as long as arguments are
technical this doesn't matter. Though when arguments are down to "Said
who? Listen to the Oracle!" it starts to.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]

On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés wrote:
> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com> wrote:
> [ snip ]
> > How can you be sure if something is "large enough" if, as you say below,
> > you do not care about probabilities?
> 
> By writing correct code?

Real world code without mistakes and larger than "Hello, world!"
exercises is not possible. Large systems must have error suppression
and correction techniques, modular and replaceable design is one of
them, KISS is another one. Systemd has none known to me.
 
> >> I don't care about probabilities;
> >
> > If you do not care (= do not now anything) about probabilities
> > (and mathematics, in general), you just unable to understand
> > that debugging a program with 200K lines of code take
> >
> > 200000!/(10000!)^20
> >
> > more time than debugging of 20 different programs with 10K lines of
> > code. You can try to calculate that number yourself but I quite sure
> > that if the latter can take, say, 20 days, the former can take
> > millions of years.
> >
> > It is all the probability! Or, to be more precise, combinatorics.
> 
> My PhD thesis (which I will defend in a few weeks) is in computer
> science, specifically computational geometry and combinatorics.

You're not the one here on the list with PhD (either defended or
near its end). And argument "Listen to me! I'm PhD here!" looks
miserable. Please stop this. 

> >> I care about facts: FACT, I've been using systemd since 2010,
> >> in several machines, and I haven't had a single segfault.
> >
> > Have you ever tried forex? If yes, you should have been warned
> > that "no past performance guarantee the future one."
> 
> I never said that. I trust the quality of the code, measured by my own
> judgment and bug reports, etc. Not past performance.
> 
> And even if a bug goes by, then what? The world will end?

This depends on what bug at what component occurred. Just imagine
pid 1 segfault on medical life support equipment. With systemd going
into embedded this is not just pure speculation, though, of course
medical stuff should have extra safeguards. But any FT or at
least HA setup is a combination of multiple layers. I do not want to
allow badly broken core component on mine setups even if its faults
may be compensated by other means.

Yet again, I respect ones right to use whatever one wants, but I ask
to respect mine as well. That's why I propose a separate systemd
profile for those willing to use it.

> >> Sorry, but it's you who doesn't know the matter at hand: kdbus was
> >> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
> >> works for the Linux Foundation.
> >
> > Lol, he seems to start to use the arguments like "You even do not know
> > my elder brother/acquaintance from the street nearby who can easily
> > hit you down!"
> 
> If you don't think Greg's words have any weight in a Linux-related
> technical discussion, then I'm afraid we will need to agree to
> disagree on any technical subject.

You know, common sense should always override person's prestige.
History knows many examples. Sir Isaac Newton enforced corpuscular
point of view on the light's nature. And while he was genius in other
physical aspects, he was mistaken here. Albert Einstein was rejective
to probabilistic nature of quantum mechanics and even proposed an
entangled particles paradox as an example of its "flawed" nature.
Though as we know these days such systems exist and are quite well
used in numerous experiments. My point is simple: do not blindly
adhere to someone's words, even if this person has high authority.
Common sense must prevail. Period.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Tue, 18 Feb 2014 20:43:22 +0400
Andrew Savchenko <bircoph@gmail.com> wrote:

> On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote:
> > > I mean, I myself know a thing or two about computing and Linux,
> > > and I promote systemd (and nobody pays me, BTW), but obviously
> > > you don't need to believe in my credentials.
> > 
> > I have said you, he is just an unpayed fanatic systemd promoter!  
> 
> Frankly, I have doubts he is unpayed.

Sorry, for partially incorrect statement. :-)

> Though as long as arguments are technical this doesn't matter.
> Though when arguments are down to "Said who? Listen to the Oracle!"
> it starts to.

It is what I meant.

Thank you for your explanations.
 
> Best regards,
> Andrew Savchenko

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
[...]
> Bugs are not equal. They differ in at least two dimensions:
> significance depending on the component affected and severity of the
> bug itself.

I've never said that they don't have different significance, severity
or scope. I said that all bugs are bugs (which is a tautology), and
that you only need to fix them once to go on.

>> > Bugs in the critical system components are
>> > critical to the whole system.
>>
>> Yeah, that's why we have unit testing and QA teams and stable and
>> unstable releases, etc.
>
> Every decent project has QA and unit tests one way or another. But
> the larger project is, the more bugs it has. And I do not want bugs
> in PID 1, that's why it should be small and sound, not bloated (even
> with some components split as separate binaries) and broken by design.

Of course the larger a project is the *potential* number of bugs
increases, but so what? With enough developers, users and testers, all
bugs are *potentially* squashed.

That's the important thing; you should not emasculate a project just
to keep it "simple" under *your* definition of simple; have you looked
at most of systemd code? It's actually pretty small and simple, and
with well defined interfaces and boundaries.

>> > If Libreoffice or browser
>> > segfaults, some data may be lost and inconvenience created, but the
>> > system will continue to run. If PID 1 segfaults — everything is
>> > lost, you have a kernel panic.
>>
>> And the world will end? The same happens if the kernel has an error.
>
> Kernel has mature error correction infrastructure (Oops handling) and
> much wider community.

And systemd has a *much* wider community than any other init system.
So it can handle a larger code base.

>> > That's why critical components should
>> > be as simple and clean as possible.
>>
>> Like the kernel? You call that "simple"?
>
> Don't mix user space and kernel space, please. There are
> more secure by design micro kernels out there (like Hurd), but
> they're out of the scope of this discussion.

I'm not mixing kernel/user space; I'm saying that critical components
don't need to be "simple"; they need to be *reliable*.

>> I'm sorry, but you are (IMO) wrong: critical components should be
>> thoroughly tested and debugged, and have integrated unit testing, and
>> a large enough group of volunteers to test new releases before they go
>> into the general public.
>
> You're pointing to valid issues, but not to the whole picture.

I just have a different point of view for the bigger picture.

> Critical components should _start_ from good design, sound modular
> architecture and _then_ with QA and testing. You're omitting the most
> important stuff, though.

But systemd has a *good* design, a modular architecture (that's why
it's splited in dozens of, you know, modules), and *besides* it has QA
and testing.

I'm not omitting nothing; I just don't share the same opinion as you
as to what constitutes a good design. And this is debatable; with
design, nothing is absolute.

>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>> > about 13 000 lines, systemd — about 200 000 lines.
>>
>> If you take into account the thousands of shell code that SysV and
>> OpenRC need to fill the functionality of systemd, they use even more.
>
> If that code will fail, this wouldn't be critical at system level.
> Thus scope of fatal error is limited.

Also in systemd, since most of its code is not critical (again;
logind, datetimed, localed, etc., failing, has no impact whatsoever on
the rest of the system).

>> > Even assuming
>> > systemd code is as mature as sysvinit or openrc (though I doubt this)
>> > you can calculate probabilities of segfaults yourself easily.
>>
>> I don't care about probabilities; I care about facts: FACT, I've been
>> using systemd since 2010, in several machines, and I haven't had a
>> single segfault. FACT: almost no bug report in systemd involves a
>> segfault in PID 1.
>
> You need facts? Here is one for you (systemd-208):
> http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg

I've never said there was no segfaults; I said I had not a single one.
Also, there are also segfaults for SysV, and for OpenRC, and for
almost any other software out there.

The important thing is the ratio of segfaults. Again, search for
yourself in the case of PID 1 in systemd. And yeah, it will be larger
than SysV, but SysV has, what, 40 years of existence? systemd has 4.

>> >> > Looks broken. Broken by design. The worst form of broken.
>> >>
>> >> By your opinion, not others.
>> >
>> > That is not just an opinion. There is a science and experience behind
>> > system's design.
>>
>> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
>> or Keith Packard of X.org fame? None of them works for Red Hat; both
>> of them know more about Unix and Linux than you and me together, and
>> both of them promote systemd.
>
> I respect Greg for most of his work, but this doesn't mean he is an
> oracle we need to adhere to. But in FOSS reputation is not that
> important, though clean technical reasons are.

You are twisting my motives to mention Greg; you said "There is a
science and experience behind system's design"; but apparently you
only care about the experience that supports your point of view. As a
counter argument I mentioned Greg and Keith because both of them have
a *LOT* of experience on Unix/Linux, and they support systemd.

>> > And all that science was ignored during systemd
>> > architecture process if there was any at all.
>>
>> You should read systemd-devel and Lennart's blog posts before saying
>> something like that. I did.
>
> I read that blog. No valid reason were found (if we're comparing
> systemd to what is outside of systemd's world, not only to bare
> sysvinit). But what I found it that blog is a lack of thorough
> project design (it looks like many components were added by the fly
> without preliminary planning) and a lot of religious statements.

Again look [1]. To me, that's a "thorough project design", and
flexible enough that it has allowed to integrate more and more
features in the four years since it was written.

You don't agree with that? That's fine, but the design is there.

We can agree to disagree if it's sound or it isn't.

Regards.

[1] http://0pointer.de/blog/projects/systemd.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 10:43 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Tue, 18 Feb 2014 04:05:03 +0200 Gevisz wrote:
>> > I mean, I myself know a thing or two about computing and Linux, and I
>> > promote systemd (and nobody pays me, BTW), but obviously you don't
>> > need to believe in my credentials.
>>
>> I have said you, he is just an unpayed fanatic systemd promoter!
>
> Frankly, I have doubts he is unpayed.

Really? You are also going to get personal.

> Though as long as arguments are
> technical this doesn't matter. Though when arguments are down to "Said
> who? Listen to the Oracle!" it starts to.

I explained in my last mail why I dropped Greg and Keith names. Don't
twist my words.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 11:06 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés wrote:
>> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com> wrote:
>> [ snip ]
>> > How can you be sure if something is "large enough" if, as you say below,
>> > you do not care about probabilities?
>>
>> By writing correct code?
>
> Real world code without mistakes and larger than "Hello, world!"
> exercises is not possible. Large systems must have error suppression
> and correction techniques, modular and replaceable design is one of
> them, KISS is another one. Systemd has none known to me.

It is modular. It is simple under the (larger) scope it tries to cover.

It will have bugs (like *any* other non-trival program, as you said),
obviously; but in time those bugs will be fixed and everything will be
fine.

>> >> I don't care about probabilities;
>> >
>> > If you do not care (= do not now anything) about probabilities
>> > (and mathematics, in general), you just unable to understand
>> > that debugging a program with 200K lines of code take
>> >
>> > 200000!/(10000!)^20
>> >
>> > more time than debugging of 20 different programs with 10K lines of
>> > code. You can try to calculate that number yourself but I quite sure
>> > that if the latter can take, say, 20 days, the former can take
>> > millions of years.
>> >
>> > It is all the probability! Or, to be more precise, combinatorics.
>>
>> My PhD thesis (which I will defend in a few weeks) is in computer
>> science, specifically computational geometry and combinatorics.
>
> You're not the one here on the list with PhD (either defended or
> near its end). And argument "Listen to me! I'm PhD here!" looks
> miserable. Please stop this.

And you please stop twisting my words. I mentioned my background only
because someone was trying to teach me about combinatorics (which has
nothing to do with this, BTW).

It was not to give any weight to any other argument.

>> >> I care about facts: FACT, I've been using systemd since 2010,
>> >> in several machines, and I haven't had a single segfault.
>> >
>> > Have you ever tried forex? If yes, you should have been warned
>> > that "no past performance guarantee the future one."
>>
>> I never said that. I trust the quality of the code, measured by my own
>> judgment and bug reports, etc. Not past performance.
>>
>> And even if a bug goes by, then what? The world will end?
>
> This depends on what bug at what component occurred. Just imagine
> pid 1 segfault on medical life support equipment. With systemd going
> into embedded this is not just pure speculation, though, of course
> medical stuff should have extra safeguards. But any FT or at
> least HA setup is a combination of multiple layers. I do not want to
> allow badly broken core component on mine setups even if its faults
> may be compensated by other means.

There are stable releases and testing releases; you put in
live-dependent code the most rock solid software you have. The one
that has been thoroughly tested and used.

Really, "small" and "modular" don't guarantee anything either; anyhow
you need to test it and use it before putting in live-dependent
systems.

> Yet again, I respect ones right to use whatever one wants, but I ask
> to respect mine as well. That's why I propose a separate systemd
> profile for those willing to use it.

Then write. Just be aware that to write a systemd profile, you need to
use systemd.

>> >> Sorry, but it's you who doesn't know the matter at hand: kdbus was
>> >> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
>> >> works for the Linux Foundation.
>> >
>> > Lol, he seems to start to use the arguments like "You even do not know
>> > my elder brother/acquaintance from the street nearby who can easily
>> > hit you down!"
>>
>> If you don't think Greg's words have any weight in a Linux-related
>> technical discussion, then I'm afraid we will need to agree to
>> disagree on any technical subject.
>
> You know, common sense should always override person's prestige.
> History knows many examples. Sir Isaac Newton enforced corpuscular
> point of view on the light's nature. And while he was genius in other
> physical aspects, he was mistaken here. Albert Einstein was rejective
> to probabilistic nature of quantum mechanics and even proposed an
> entangled particles paradox as an example of its "flawed" nature.
> Though as we know these days such systems exist and are quite well
> used in numerous experiments. My point is simple: do not blindly
> adhere to someone's words, even if this person has high authority.
> Common sense must prevail. Period.

I don't blindly adhere to *anyone* points. There are arguments that
Greg, Lennart and Kay had made which I don't agree with.

But in the big picture I'm with those guys. And so it seems the
majority of the Linux world; you say it's because monetary reasons. I
said it is because of the technical advantages of systemd.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

I'll try to be short.

On 18.02.2014 05:09, Canek Peláez Valdés wrote:
>> The whole point of creating new software is making things easier. Easier to
>> use, easier to maintain, easier to remove.
>
> Well, systemd is easier to use after a little time learning how it
> works. And it seems to be easier to maintain that thousands of lines
> of spaghetti shell code. And, I'm sorry, did you just said "easier to
> remove"? Seriously?

You, as a person declaring ability to code, must understand what 
removal/substitution of components is important for.

> You think the kernel is "easier to remove"? Or glibc?

The difference is, the kernel wasn't designed to be removed, neither was 
glibc. I don't think the development of such projects as 
Debian/kFreeBSD, uClibc etc is easy. Systemd is going to be even harder 
to remove -- officially limiting itself to Linux kernels.

>> How Integrated? The TCP/IP stack *is* integrated. But it is *protocol*
>> integration, *standards* integration not *software* integration. You do want
>> tight integration where it just can't work otherwise, but the design of Unix
>> provides (well, again repeating this), and almost any robust design should
>> provide, the ignorance of one abstraction level about another. Why HAL? Why
>> udev? Why drivers as modules? Why not just go and integrate all stuff into
>> the kernel, well (again!) like MS do, and don't please say I compare wrong
>> things just because MS is not OSS.
>
> You make a wrong comparison, because MS is not free (libre) software.
> With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we
> have been able to try new technologies (and see that some of them
> fail, like HAL [yuck!]), because we have the source.

I knew you'd say this, ignoring my warning. Will you also claim that 
comparing Oracle and Postgres also doesn't have sense? Or comparing 
Photoshop and GIMP?

> As you said, you can replace the whole of Linux if you so desire (and
> have the technical ability).
>
> You will never be able to do that with any MS software, and so the
> comparison makes no sense.

BTW, I asked purely technically: why not integrate everything into the 
kernel, since we're having a working example?

>> -- not because of its design, technical details etc, but
>> because otherwise in short time you'll end up comparing systemd to itself.
>
> ?

...because there'll be nothing left to compare systemd to.

> The code is out there. You can choose to pick any point in time of the
> whole stack (ca. 2009, before systemd existed), and wrote from there
> if you have enough people willing and able to.

So you eventually agree that it all converges on money. Enough people, 
competent enough in init systems, is quite 'enough' money.

> No one is taking anything from any one. No one is forcing nothing.

No, no. No forcing. Just an offer you can't refuse.

> Free software is being written and offered, and knowledgeable people
> are choosing to use it in their distros.
>
> You are against that? Then wrote your own version with the same (or
> better) features.

Heck of an argument. You don't like that stupid program on your TV? 
C'mon broadcast yours own. You don't like that road crossing with 
hundreds of traffic accidents? C'mon stand there directing traffic 
instead of the road police. Etc.
You call the software free? Then put up with criticism and make 
conclusions on the feedback. If you don't or can't, don't claim it's 
free software.

Nothing personal, Canek, I respect your POV and your eagerness to help 
people and make the world better that you always show in this ML. :)

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 8169 bytes --]

On Mon, 17 Feb 2014 18:49:47 -0600 Canek Peláez Valdés wrote:
> > The whole deep integration approach and lack of
> > inter-module boundaries doesn't allow one to write replaceable blocks
> > without crazy hacking.
> 
> Well, then go and show them how it's done. And please don't say that
> "it's already done", because if that were the case, no distro would
> have adopted systemd.
> 
> They adopted it because of the features it offers.

What features? As far as I can see if we compare to openrc, the only
missed feature is logind for which it is declared to be better than
consolekit. I can't argue here because I never used either one.

At this moment I have about 50 Gentoo boxes (in hardware) at my
control including both personal and work hardware including laptops,
desktops, production servers and two HPC setups (not to count
hundreds of LXC containers). And I see neither reason nor need for
systemd here.

From what I can see, all this systemd boom started from Gnome's GDM
dropping support for anything aside from systemd. Afterwards
distributions started to switch to systemd one after another in order
to fully support Gnome-3 setups. And now we have a little fact here:
Lennart Poettering is a long time Gnome contributor. Which leads me to
only one conclusion: situation we have now is a deliberate sabotage
in order to acquire as much influence by RH as possible. Influence
leads to a sales market expansion, which leads to a profit. So we
have money here as a root cause of all this boom — a root of all evil
and a root of systemd. All "features and benefits" are nothing more
than just an excuse for the aim for market domination and more profit.

> > Just imagine that one have PCI-E bus and this bug is being replaced
> > with some other PC-systemd bus, where one have to interface each
> > component differently. And if one removes e.g. audio card some other
> > seemingly independent component e.g. network controller becomes
> > broken. That is the nature of systemd and that is many people dislike
> > this technology.
> 
> That is a broken analogy; if logind has a bug, that doesn't affect
> timedated, nor udev.

No, it is not. You can not remove systemd-udevd and replace it
with mdev or static dev without broking most of other systemd
components. The same way in my analogy you can not remove audio card
without broking network controller.

> >> > That said, it seems to me that, for now at least, it isn't that big a deal
> >> > to switch back and forth between systemd and, for example, OpenRC.
> >>
> >> It depends; right now you can't switch back and forth between OpenRC
> >> and systemd without reemerging some stuff. Some of those packages
> >> *could* be made to switch functionality at run time instead of compile
> >> time, but SOMEONE has to write that support, and it's probably that
> >> the upstream for the package will not accept those changes, since for
> >> binary distributions it makes no sense to have the complexity on the
> >> code of switching behavior at runtime when doing at compile time is
> >> easier and the distribution generates one binary per architecture for
> >> all its users.
> >
> > The most sane and fair solution was already proposed: create a
> > systemd profile for those who need it. I personally highly dislike
> > systemd technology, but I respect the right of other to shoot them in
> > the leg (or head) as much as they want to. This is Gentoo: a universal
> > constructor providing people means to build any system in any shape
> > they need.
> 
> If someone willing and able provides any choice, that choice will be available.

What choice? For features neither used nor needed before? Before
systemd we had our choice: sysvinit, openrc, runit, epoch... By
enforcing unwanted features to us systemd takes our freedom and our
choice.
 
> > Unfortunately chances are that in future some software may become
> > unusable or unsupported outside of systemd profile. But patches may
> > be created and other profiles will continue to live the same way
> > hardened exists now and will continue to exist later.
> 
> Yeah, and that's my whole point: if you want that the world outside of
> systemd keeps working, you need to step in. Complaining about systemd
> will get no one nowhere.

That's the point of systemd adepts: we'll break things the way we
want, fix them yourself if you dare. Behind the curtain you're just
offloading your work to others or, more precisely, your time efforts
to others. I don't like that. Do whatever you want to do, but please
do not be intrusive into other domains and respect the freedom of
choice of others.
 
> > BTW it was shown at the recent LVEE Winter 2014 conference that GDM
> > can be easily freed from systemd and OpenBSD guys have an interesting
> > idea for faking systemd presence for applications requesting one
> > mandatory. Though IMO any end-user application strictly dependable on
> > any init system is broken by design: for a daemon there should be no
> > difference by which tool it was started.
> 
> GNOME depends on logind, not systemd. And no one has been willing and
> able to produce a compatible replacement: logind works with a dbus
> API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu
> has been working in a replacement, but (AFAIU) is not finished.

And logind hardly depends on systemd . That's why Gnome depends on
systemd.

> > The real reason is money: systemd is a Red
> > Hat project (despite being formally open for everyone) and is their
> > tool^Wweapon to fight with Canonical for a sales market. It the last
> > years RH was pushed near even in a server market and now they are
> > fighting back.
> 
> Nice conspiracy theory you have going on.

You may call facts as like as you want to. This will not change them.
 
> > They were lucky enough to acquire Poettiring guy and
> > create from a simple and sound sysvinit (which is an important but
> > not dictating peace of software) a key component where they can
> > dictate their own line, where they can lead all Linux community in
> > a way they need.
> 
> And it gets better. Citation needed? Any hard proof?

Citation for what? You're free to analyze fact and trends yourself.
 
> > That the real reason I despise systemd: in replaces the freedom of
> > choice by a dictatorship of a small bunch of managers of a single
> > corporation (yes, managers, not developers). And all this is under the
> > veil of GPL and technical merits. This is the poison in the well of
> > FOSS.
> 
> I don't work for RedHat; I teach in a University. Nobody pays me for
> using systemd; I just choose to because I think is a technical sound
> solution for the chaos that was the plumbing layer in Linux.

This chaos is called freedom, freedom of choice, which leads to
diversity, evolution and security. With every system unified in
its core component we'll have a nice single and easily targeted point
of failure. With systemd on most Linux distributions viruses (in
terms of self-spreading windows malware) are just a matter of time.
If this folly will not be stopped before it's spread you may recall my
words in about five years.

> The technical merits and advantages of systemd are there in the open
> for anyone willing to study a little about it. *After* you carefully
> read the code, the documentation, and test the software in real life,
> you *may* still think you don't like the software or its design.

Believe me or not, but I tested it, I read its docs and I studied its
code. I vomited.

There are two major types of failures: design failure and
implementation failure. I'm tolerant to implementation issues, anyone
have them after all. But monolithic deeply integrated approach is
flawed by design. Even this issue can be tolerated as long as project
is supposed to be compatible and replaceable with other solutions
(remember, everyone has right to shoot oneself in the leg). But if
project is being aggressively enforced, this is no way to go.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 11:24 AM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> I'll try to be short.
[ snip ]
> You, as a person declaring ability to code, must understand what
> removal/substitution of components is important for.

In some cases it is; in some others it just creates a chaos, like it
was the plumbing layer in Linux before systemd.

>> You think the kernel is "easier to remove"? Or glibc?
>
> The difference is, the kernel wasn't designed to be removed, neither was
> glibc. I don't think the development of such projects as Debian/kFreeBSD,
> uClibc etc is easy. Systemd is going to be even harder to remove --
> officially limiting itself to Linux kernels.

I agree with you on this one: systemd is *not* designed to be removed.
But at not point has anybody said anything about not being able to use
Linux (the kernel) without systemd.

That it could happen anyhow? It's possible. Don't want it to happen?
Write code that doesn't needs systemd.

It's really that simple.

[ snip ]
>> You make a wrong comparison, because MS is not free (libre) software.
>> With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we
>> have been able to try new technologies (and see that some of them
>> fail, like HAL [yuck!]), because we have the source.
>
> I knew you'd say this, ignoring my warning. Will you also claim that
> comparing Oracle and Postgres also doesn't have sense? Or comparing
> Photoshop and GIMP?

Well, it depends. It's totally valid to compare Linux with Windows as
OSes. It's totally valid to compare Photoshop to Gimp as image
editors. It's totally valid to compare Oracle and PostgreSQL as
databases.

It's *NOT* valid to compare Microsoft to the Linux Foundation (for the
arguments I gave). It's *NOT* valid to compare Adobe to the Gimp
developers. It's *NOT* valid to compare Oracle (the company) to the
PostgreSQL Global Development Group.

It's *NOT* valid to compare the lock-in enforced by Microsoft, to
software libre being created by RedHat employers.

>> As you said, you can replace the whole of Linux if you so desire (and
>> have the technical ability).
>>
>> You will never be able to do that with any MS software, and so the
>> comparison makes no sense.
>
> BTW, I asked purely technically: why not integrate everything into the
> kernel, since we're having a working example?

I'm pretty sure someone crazy enough did this. But nobody in the
community will want to use that code.

Some years ago, someone sent a patch to the LKML to support "single
mode Linux" (basically removing multiuser support). Nobody wanted to
use that code either.

On the contrary, a *lot* of people want to use systemd. I do, the
GNOME project does, Debian just choose it, etc.

See the difference?

>>> -- not because of its design, technical details etc, but
>>> because otherwise in short time you'll end up comparing systemd to
>>> itself.
>>
>> ?
>
> ...because there'll be nothing left to compare systemd to.

I'm pretty sure OpenRC will never go away (and neither SysV, BTW). And
if you want alternatives to systemd, *write them*.

>> The code is out there. You can choose to pick any point in time of the
>> whole stack (ca. 2009, before systemd existed), and wrote from there
>> if you have enough people willing and able to.
>
> So you eventually agree that it all converges on money. Enough people,
> competent enough in init systems, is quite 'enough' money.

No, I don't agree with your monetary reasons. Almost nobody payed for
Linux development at the beginning. Nor for GNOME development, at the
beginning. And, AFAIK, nobody actually pay for Gentoo development
(everybody, make a donation!)

If some willing and able want to, they will support anything. Being
payed or not.

>> No one is taking anything from any one. No one is forcing nothing.
>
> No, no. No forcing. Just an offer you can't refuse.

You CAN refuse. It's just that no one is going to do the work for you.

>> Free software is being written and offered, and knowledgeable people
>> are choosing to use it in their distros.
>>
>> You are against that? Then wrote your own version with the same (or
>> better) features.
>
> Heck of an argument. You don't like that stupid program on your TV? C'mon
> broadcast yours own.

The analogy doesn't make sense; I use my Linux boxen to work, and I
(personally) don't watch TV (at least from the air).

> You don't like that road crossing with hundreds of
> traffic accidents? C'mon stand there directing traffic instead of the road
> police. Etc.

Another analogy that doesn't makes sense. I pay taxes so my government
fixes the road crossing.

> You call the software free? Then put up with criticism and make conclusions
> on the feedback. If you don't or can't, don't claim it's free software.

Hey, I'm here putting up with criticism and feedback for software I
didn't even make!

> Nothing personal, Canek, I respect your POV and your eagerness to help
> people and make the world better that you always show in this ML. :)

Thanks; the thing is, really, that in 1996 when I joined the Linux
community, if someone found anything they didn't like it or had a
better idea, they contributed. Not necessarily with code;
documentation, bug reports, testing.

Nowadays, cool software (from my POV) is made available, and I hear a
lot of people whining and complaining and saying they are being forced
to use it... When from the start nobody is forcing anyone to use
Linux, AFAIK.

And with Linux (and contrary to Windows or MacOS, and similar to the
pletora of *BSDs), you *can* influence the direction of any part of
the stack that you want.

But you need to put your code (or bug reports, documentation, etc.)
where your mouth is.

I don't see much of the latter.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
> > Yet again, I respect ones right to use whatever one wants, but I ask
> > to respect mine as well. That's why I propose a separate systemd
> > profile for those willing to use it.
> 
> Then write. Just be aware that to write a systemd profile, you need to
> use systemd.

Or to create a non-systemd profile :)

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 11:44 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Mon, 17 Feb 2014 18:49:47 -0600 Canek Peláez Valdés wrote:
>> > The whole deep integration approach and lack of
>> > inter-module boundaries doesn't allow one to write replaceable blocks
>> > without crazy hacking.
>>
>> Well, then go and show them how it's done. And please don't say that
>> "it's already done", because if that were the case, no distro would
>> have adopted systemd.
>>
>> They adopted it because of the features it offers.
>
> What features? As far as I can see if we compare to openrc, the only
> missed feature is logind for which it is declared to be better than
> consolekit. I can't argue here because I never used either one.

Exactly.

I (and many others) do *use* those features. We *want* those features.
Therefore, distros want to *provide* those features, because I'm not
in the minority.

If you don't wnat those features that's fine, of course.

> At this moment I have about 50 Gentoo boxes (in hardware) at my
> control including both personal and work hardware including laptops,
> desktops, production servers and two HPC setups (not to count
> hundreds of LXC containers). And I see neither reason nor need for
> systemd here.

That's fine; I think it would make your life easier, specially with
the containers (check out systemd-nspawn), but nobody is forcing you
to use systemd.

> From what I can see, all this systemd boom started from Gnome's GDM
> dropping support for anything aside from systemd. Afterwards
> distributions started to switch to systemd one after another in order
> to fully support Gnome-3 setups. And now we have a little fact here:
> Lennart Poettering is a long time Gnome contributor. Which leads me to
> only one conclusion: situation we have now is a deliberate sabotage
> in order to acquire as much influence by RH as possible. Influence
> leads to a sales market expansion, which leads to a profit. So we
> have money here as a root cause of all this boom — a root of all evil
> and a root of systemd. All "features and benefits" are nothing more
> than just an excuse for the aim for market domination and more profit.

I've never payed RedHat a single cent. I've donated money to some
Linux projects, but never to RedHat. I really don't see your point: I
*want* the features systemd provides, it makes *my* life easier.

Mine and of many others.

That is completely orthogonal to you using (or not) or wanting (or not) systemd.

>> > Just imagine that one have PCI-E bus and this bug is being replaced
>> > with some other PC-systemd bus, where one have to interface each
>> > component differently. And if one removes e.g. audio card some other
>> > seemingly independent component e.g. network controller becomes
>> > broken. That is the nature of systemd and that is many people dislike
>> > this technology.
>>
>> That is a broken analogy; if logind has a bug, that doesn't affect
>> timedated, nor udev.
>
> No, it is not. You can not remove systemd-udevd and replace it
> with mdev or static dev without broking most of other systemd
> components. The same way in my analogy you can not remove audio card
> without broking network controller.

But you can remove logind (and systemd, in fact), and have udev working.

The others are simple software dependencies. You cannot remove Gtk+
from GNOME, nor Qt from KDE. You cannot remove Linux if you want to
use LXC.

What's the problem with that?

>> >> > That said, it seems to me that, for now at least, it isn't that big a deal
>> >> > to switch back and forth between systemd and, for example, OpenRC.
>> >>
>> >> It depends; right now you can't switch back and forth between OpenRC
>> >> and systemd without reemerging some stuff. Some of those packages
>> >> *could* be made to switch functionality at run time instead of compile
>> >> time, but SOMEONE has to write that support, and it's probably that
>> >> the upstream for the package will not accept those changes, since for
>> >> binary distributions it makes no sense to have the complexity on the
>> >> code of switching behavior at runtime when doing at compile time is
>> >> easier and the distribution generates one binary per architecture for
>> >> all its users.
>> >
>> > The most sane and fair solution was already proposed: create a
>> > systemd profile for those who need it. I personally highly dislike
>> > systemd technology, but I respect the right of other to shoot them in
>> > the leg (or head) as much as they want to. This is Gentoo: a universal
>> > constructor providing people means to build any system in any shape
>> > they need.
>>
>> If someone willing and able provides any choice, that choice will be available.
>
> What choice? For features neither used nor needed before?

*You* don't need them; *you* don't use them. Many of us do.

> Before
> systemd we had our choice: sysvinit, openrc, runit, epoch... By
> enforcing unwanted features to us systemd takes our freedom and our
> choice.

Who's enforcing anything on you? Go on and roll your own Linux
distribution free from the systemd "virus".

You will be *always* be able to do that, because the software is free.

>> > Unfortunately chances are that in future some software may become
>> > unusable or unsupported outside of systemd profile. But patches may
>> > be created and other profiles will continue to live the same way
>> > hardened exists now and will continue to exist later.
>>
>> Yeah, and that's my whole point: if you want that the world outside of
>> systemd keeps working, you need to step in. Complaining about systemd
>> will get no one nowhere.
>
> That's the point of systemd adepts: we'll break things the way we
> want, fix them yourself if you dare.

No, the software (as you said) worked before systemd arrived, right?
Then maintain it from the last version that didn't need it systemd.
Problem solved.

> Behind the curtain you're just
> offloading your work to others or, more precisely, your time efforts
> to others.

No; you want to offload the work to the maintainers. The maintainers
(usually) want to support the largest number of users; systemd
provides features that make maintainers life easier, so they choose
it. Then the distribution chooses systemd, since several projects
anyhow requires systemd.

*You* don't want systemd; but you are not the one writing the code for
the package, or the project, nor the distribution. Guess what? The
people writing the software makes the choices.

You want the maintainers do the job of the  so it works without
systemd, when that's actually *more* work for them. Why should they
listen to you?

Go around and gather all the systemd-haters. Make them work so the
package/project/distribution keeps working without systemd. Not enough
talented people? Well, that's not the maintainer problem, is it?

> I don't like that. Do whatever you want to do, but please
> do not be intrusive into other domains and respect the freedom of
> choice of others.

I don't care about anyone else choices. The choice is there; the
software is FREE. I don't force anyone to use anything (how could I?,
how could anyone?)

>> > BTW it was shown at the recent LVEE Winter 2014 conference that GDM
>> > can be easily freed from systemd and OpenBSD guys have an interesting
>> > idea for faking systemd presence for applications requesting one
>> > mandatory. Though IMO any end-user application strictly dependable on
>> > any init system is broken by design: for a daemon there should be no
>> > difference by which tool it was started.
>>
>> GNOME depends on logind, not systemd. And no one has been willing and
>> able to produce a compatible replacement: logind works with a dbus
>> API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu
>> has been working in a replacement, but (AFAIU) is not finished.
>
> And logind hardly depends on systemd . That's why Gnome depends on
> systemd.

There is (apparently) no one willing and able to write a replacement.
Again, that's not systemd's fault, nor GNOME's, which wants to use
it's features.

>> > The real reason is money: systemd is a Red
>> > Hat project (despite being formally open for everyone) and is their
>> > tool^Wweapon to fight with Canonical for a sales market. It the last
>> > years RH was pushed near even in a server market and now they are
>> > fighting back.
>>
>> Nice conspiracy theory you have going on.
>
> You may call facts as like as you want to. This will not change them.

Facts are backed by evidence; otherwise is hearsay.

>> > They were lucky enough to acquire Poettiring guy and
>> > create from a simple and sound sysvinit (which is an important but
>> > not dictating peace of software) a key component where they can
>> > dictate their own line, where they can lead all Linux community in
>> > a way they need.
>>
>> And it gets better. Citation needed? Any hard proof?
>
> Citation for what? You're free to analyze fact and trends yourself.

I just did analyze them above. I think you will demise my analysis,
like I do yours.

>> > That the real reason I despise systemd: in replaces the freedom of
>> > choice by a dictatorship of a small bunch of managers of a single
>> > corporation (yes, managers, not developers). And all this is under the
>> > veil of GPL and technical merits. This is the poison in the well of
>> > FOSS.
>>
>> I don't work for RedHat; I teach in a University. Nobody pays me for
>> using systemd; I just choose to because I think is a technical sound
>> solution for the chaos that was the plumbing layer in Linux.
>
> This chaos is called freedom, freedom of choice, which leads to
> diversity, evolution and security.

The choice is there for you to evolve any free software you want to.
Systemd has certainly evolved since its inception 4 years ago.

> With every system unified in
> its core component we'll have a nice single and easily targeted point
> of failure.

That's a valid point. Good thing a very large group of very
experienced, very capable people (with members from basically every
distribution under the sun, including Gentoo) is working in making
this core component as rock solid as possible.

> With systemd on most Linux distributions viruses (in
> terms of self-spreading windows malware) are just a matter of time.

Let's see. I highly doubt it; I mean, Fedora, OpenSuse and Arch have
been using systemd for years now, and it hasn't happened yet.

> If this folly will not be stopped before it's spread you may recall my
> words in about five years.

Wanna bet a beer it doesn't happen? I'm willing to bet a beer.

(I don't drink beer, BTW).

>> The technical merits and advantages of systemd are there in the open
>> for anyone willing to study a little about it. *After* you carefully
>> read the code, the documentation, and test the software in real life,
>> you *may* still think you don't like the software or its design.
>
> Believe me or not, but I tested it, I read its docs and I studied its
> code. I vomited.

I believe you. I respect your opinion. I do not share it. So I think
the sane thing to do is to agree to disagree.

> There are two major types of failures: design failure and
> implementation failure. I'm tolerant to implementation issues, anyone
> have them after all. But monolithic deeply integrated approach is
> flawed by design. Even this issue can be tolerated as long as project
> is supposed to be compatible and replaceable with other solutions
> (remember, everyone has right to shoot oneself in the leg). But if
> project is being aggressively enforced, this is no way to go.

Again, I agree to disagree with you.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>> > Yet again, I respect ones right to use whatever one wants, but I ask
>> > to respect mine as well. That's why I propose a separate systemd
>> > profile for those willing to use it.
>>
>> Then write. Just be aware that to write a systemd profile, you need to
>> use systemd.
>
> Or to create a non-systemd profile :)

That's the best response I've read in, like, many years. That's
perfect; I'm 100% behind it. I even volunteer to help (with testing)
to anyone going for this.

You guys create a systemd-sucks-we-dont-want-it profile, and I promise
to give you guys a hand.

Make a profile that "frees" users from using systemd, and I think even
several Gentoo developers will get behind that.

Now we are talking; this has been my whole point the whole time.
Everybody that don't want to use systemd; help this idea, and if there
are enough of you, you'll pulled through.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-18 1:14 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
>> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>>>> Yet again, I respect ones right to use whatever one wants, but I ask
>>>> to respect mine as well. That's why I propose a separate systemd
>>>> profile for those willing to use it.
>>>
>>> Then write. Just be aware that to write a systemd profile, you need to
>>> use systemd.
>>
>> Or to create a non-systemd profile :)
>
> That's the best response I've read in, like, many years. That's
> perfect; I'm 100% behind it. I even volunteer to help (with testing)
> to anyone going for this.

Canek,

You've referred many times to other programs that *require* systemd.

I'm curious as to the extent of these programs, and to what extent they 
*truly* require systemd.

I can't for the life of me think of any reason that server daemons like 
postfix, dovecot, apache, etc would or could ever *require* systemd.

I couldn't care less about gnome (don't use it, never used it, don't 
wanna use it), but what others are there?

Also, for those that do require it, what feature of systemd (that 
doesn't have an alternative available) is it that the program uses?

Thx

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[the]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/18/14 17:56, Gevisz wrote:
> On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés
> <caneko@gmail.com> wrote:
> 
>> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com>
>> wrote: [ snip ]
>>> How can you be sure if something is "large enough" if, as you
>>> say below, you do not care about probabilities?
>> 
>> By writing correct code?
> 
> No, by arguing that fixing bugs in a 200K line program is as easy
> as fixing a bug in 20 10K line programs. It is just not true, just
> the opposite.
> 
>>>>> SysVinit code size is about 10 000 lines of code, OpenRC
>>>>> contains about 13 000 lines, systemd — about 200 000
>>>>> lines.
>>>> 
>>>> If you take into account the thousands of shell code that
>>>> SysV and OpenRC need to fill the functionality of systemd,
>>>> they use even more.
>>>> 
>>>> Also, again, systemd have a lot of little binaries, many of
>>>> them optional. The LOC of PID 1 is actually closer to SysV
>>>> (although still bigger).
>>>> 
>>>>> Even assuming systemd code is as mature as sysvinit or
>>>>> openrc (though I doubt this) you can calculate
>>>>> probabilities of segfaults yourself easily.
>>>> 
>>>> I don't care about probabilities;
>>> 
>>> If you do not care (= do not now anything) about probabilities 
>>> (and mathematics, in general), you just unable to understand 
>>> that debugging a program with 200K lines of code take
>>> 
>>> 200000!/(10000!)^20
>>> 
>>> more time than debugging of 20 different programs with 10K
>>> lines of code. You can try to calculate that number yourself
>>> but I quite sure that if the latter can take, say, 20 days, the
>>> former can take millions of years.
>>> 
>>> It is all the probability! Or, to be more precise,
>>> combinatorics.
>> 
>> My PhD thesis (which I will defend in a few weeks) is in
>> computer science, specifically computational geometry and
>> combinatorics.
> 
> It is even more shameful for you to not understand such a simple
> facts from elementary probability theory (which is mostly based on 
> combinatorics).
TBH I don't understand your estimate. Where did permutations come
from? are you comparing all the different combinations of lines of code?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTA6wWAAoJEK64IL1uI2ha5nIH/iUl2VNVAabzJzRJzC29zmWg
t7KwGcfrtx2D40N7n4yM4LB7VBmnyoQ6+Iroh/uk3S33S/YK/5igN8UfuhvV+lvU
85X3T3RE3oK3kURLq68bb4Ri2zLFQ8y1rQdrrUr9ABzy+F4Xfo+W4t+lLsHSQ+dY
f4F7ByfJAHwh9OziFKh2/qwLj4z0Trv8AzZZhP8M29kTNWEWGyo5rGg8vRqm8Klm
kHR3RvvTdV4AgYGHqxdtrO7qpB50VXZA8ihzl7lbmsBJj3pWBo1osFNWNP82yy7r
s4hev5QrCpgOlEebtYi/noX8Vxx335SUirGCgjN/W9xhIwt3jfMqRes6zD+bi7A=
=F5to
-----END PGP SIGNATURE-----

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-18 1:14 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko <bircoph@gmail.com>
>> wrote:
>>>
>>> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>>>>>
>>>>> Yet again, I respect ones right to use whatever one wants, but I ask
>>>>> to respect mine as well. That's why I propose a separate systemd
>>>>> profile for those willing to use it.
>>>>
>>>>
>>>> Then write. Just be aware that to write a systemd profile, you need to
>>>> use systemd.
>>>
>>>
>>> Or to create a non-systemd profile :)
>>
>>
>> That's the best response I've read in, like, many years. That's
>> perfect; I'm 100% behind it. I even volunteer to help (with testing)
>> to anyone going for this.
>
>
> Canek,
>
> You've referred many times to other programs that *require* systemd.

I meant in the Gentoo context (more below).

And programs depend on *features* provided by systemd, not PID 1. I
don't think any program will ever require a certain PID 1, and I would
call that a bug.

> I'm curious as to the extent of these programs, and to what extent they
> *truly* require systemd.

I don't understand what you mean by "the extent of these programs". As
"to what extent they *truly* require systemd", the don't require
systemd the package, they require some of the features provided by it.
In particular, logind it's the one being used by GNOME (and Xfce and
KDE soon, optionally, as in GNOME).

> I can't for the life of me think of any reason that server daemons like
> postfix, dovecot, apache, etc would or could ever *require* systemd.

Neither of those packages would ever require systemd (nor any init
system). If they do, I would call that a bug.

All of those programs can use features provided by systemd (like
socket activation, using the more advances features of the journal,
etc.), but they can be made optional.

> I couldn't care less about gnome (don't use it, never used it, don't wanna
> use it), but what others are there?

Well, KDE is talking about doing basically the same as GNOME and using
logind. ConsoleKit will be still supported, as is (technically) in
GNOME,  and I just read that CK is actually being maintained. I don't
know if it's getting new features, though, and logind is.

> Also, for those that do require it, what feature of systemd (that doesn't
> have an alternative available) is it that the program uses?

Again, basically logind. And there *is* ConsoleKit available as an alternative.

But basically all the GNOME developers are using systemd, so the CK
support is getting bitrotten. That's why the Gentoo GNOME team decided
to depend on systemd, although the requirement is really logind.

If *someone* creates a logind compatible replacement (it uses a simple
dbus API[1]), then even the GNOME suit in Gentoo could drop the
requirement for systemd. Ubuntu has been working on something like
this, and Mark Shuttleworth said that they will continue to work on
it, even with Ubuntu choosing systemd[2], so if/when that's available,
there will be no program that *requires* systemd, AFAIK.

(Well, gnome-logs depends on the journal, but it's a GUI for a systemd
specific feature).

Like I've been saying; no one is forcing nothing on no one. But
someone has to write/support/maintain the alternative.

Regards.

[1] http://www.freedesktop.org/wiki/Software/systemd/logind/
[2] http://www.markshuttleworth.com/archives/1316
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-18 1:54 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:> On 
Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
 >> I'm curious as to the extent of these programs, and to what extent
 >> they *truly* require systemd.

 > I don't understand what you mean by "the extent of these programs".

Sorry, worded that badly... I meant, basically, how many programs now 
require systemd...

>> I can't for the life of me think of any reason that server daemons
>> like postfix, dovecot, apache, etc would or could ever *require*
>> systemd.

 > Neither of those packages would ever require systemd (nor any init
 > system). If they do, I would call that a bug.

Then why should XFCE requiring it also not be a bug?

I totally get XFCE *supporting* the use of logind, but why should it 
ever support *only* logind? That would seem insane to me.

 > All of those programs can use features provided by systemd (like
 > socket activation,

OpenRC will supposedly soon support the use of sockets...

 > using the more advances features of the journal, etc.), but they can
 > be made optional.

Exactly... it is the question of *requiring* it, or *only* supporting 
it, that doesn't make sense to me.

>> Also, for those that do require it, what feature of systemd (that
>> doesn't have an alternative available) is it that the program
>> uses?

 > Again, basically logind. And there *is* ConsoleKit available as an
 > alternative.

Ok, so the numerous times you and others have made comments about the 
'many new features' of systemd, you only really meant logind?

 > But basically all the GNOME developers are using systemd, so the CK
 > support is getting bitrotten. That's why the Gentoo GNOME team decided
 > to depend on systemd, although the requirement is really logind.
 >
 > If *someone* creates a logind compatible replacement (it uses a simple
 > dbus API[1]), then even the GNOME suit in Gentoo could drop the
 > requirement for systemd. Ubuntu has been working on something like
 > this, and Mark Shuttleworth said that they will continue to work on
 > it, even with Ubuntu choosing systemd[2], so if/when that's available,
 > there will be no program that *requires* systemd, AFAIK.
 >
 > (Well, gnome-logs depends on the journal, but it's a GUI for a systemd
 > specific feature).
 >
 > Like I've been saying; no one is forcing nothing on no one. But
 > someone has to write/support/maintain the alternative.

Excellent... so apparently, the only real new features that have any 
kind of dependency are logind and maybe journald, so all that would be 
needed are compatible replacements, and all of the noise about systemd 
consuming the world has been just that... noise?

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[gottlieb]

On Tue, Feb 18 2014, Canek Peláez Valdés wrote:

> On Tue, Feb 18, 2014 at 2:19 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
>> The 17/02/14, Canek Peláez Valdés wrote:
>>
>>> It depends; right now you can't switch back and forth between OpenRC
>>> and systemd without reemerging some stuff.
>>
>> Interesting. Didn't know that. What packages need to be recompiled?
>
> Some packages need to be emerged with USE="-systemd" when going from
> systemd to OpenRC, and with USE="systemd" the other way around.
> Different code paths are selected in each case.

I think the consolekit USE flag also has to be changed.
Systemd: USE="+systemd -consolkit"
OpenRC:  USE="-systemd +consolkit"

At least that is what I did when I switched OpenRC-->Systemd (with
Canek's help).  Now I have no global USE flags, thanks to the systemd
subprofile.

newlap-wireless gottlieb # eselect profile show
Current /etc/portage/make.profile symlink:
  default/linux/amd64/13.0/desktop/gnome/systemd
newlap-wireless gottlieb # 

allan

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

On Tue, 18 Feb 2014 22:07:12 +0400, Andrew Savchenko wrote:

> > Then write. Just be aware that to write a systemd profile, you need to
> > use systemd.  
> 
> Or to create a non-systemd profile :)

We already have many of those, because systemd is not the default. Part
of making it the default, if that decision is ever taken, would be to
modify the current profiles to support systemd, at which point the old
versions would become the non-systemd profiles.

Yes, it does take systemd users/devs to create a systemd profile, but
they are the one that will want to use it anyway. The rest already have
what they want.

This is the way things have moved with the GNOME and KDE profiles, expect
others to follow suit.

I'm still uncomfortable with the pervasiveness of systemd, although Canek
does put forward persuasive arguments, through a mixture of expertise and
remaining calm. So GNOME want to use logind, which may well be superior
to ConsoleKit, but why should that require a change of init system?

A login daemon should be started by the init system, not be an integral
part of it. What happens when logind no longer fulfils developers needs,
as is the case with ConsoleKit now, how can it be replaced with an
improved service when it is so closely tied to the init system.


-- 
Neil Bothwick

Windows '96 artificial intelligence: Unable to FORMAT A: Having a go at C:

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 1:09 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-18 1:54 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:> On
> Tue, Feb 18, 2014 at 12:31 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>> I'm curious as to the extent of these programs, and to what extent
>>> they *truly* require systemd.
>
>> I don't understand what you mean by "the extent of these programs".
>
> Sorry, worded that badly... I meant, basically, how many programs now
> require systemd...

The packages requiring loingd.

>>> I can't for the life of me think of any reason that server daemons
>>> like postfix, dovecot, apache, etc would or could ever *require*
>>> systemd.
>
>> Neither of those packages would ever require systemd (nor any init
>> system). If they do, I would call that a bug.
>
> Then why should XFCE requiring it also not be a bug?

If XFCE requires systemd the *init system*, I agree it's a bug.

> I totally get XFCE *supporting* the use of logind, but why should it ever
> support *only* logind? That would seem insane to me.

If someone writes the support for non-logind systems (like the *BSDs),
everything is dandy and you and I are happy as clams.

>> All of those programs can use features provided by systemd (like
>> socket activation,
>
> OpenRC will supposedly soon support the use of sockets...

I suppose it will be different; but probably it can be made to work
for both. Again, if *someone* writes the support for each.

>> using the more advances features of the journal, etc.), but they can
>> be made optional.
>
> Exactly... it is the question of *requiring* it, or *only* supporting it,
> that doesn't make sense to me.

If the project supports both no one will complain. The thing is that
there will be projects that will only actively support logind, because
it works so much better than ConsoleKit. That's the case with GNOME.

If someone writes the famous logind replacement, again, everybody is
happy as a clam.

>>> Also, for those that do require it, what feature of systemd (that
>>> doesn't have an alternative available) is it that the program
>>> uses?
>
>> Again, basically logind. And there *is* ConsoleKit available as an
>> alternative.
>
> Ok, so the numerous times you and others have made comments about the 'many
> new features' of systemd, you only really meant logind?

No, we meant logind, the journal, hostnamed, timedated, the socket
activation, the new networking tool that will arrive with 209, and all
the features to handle and monitor services.

By the way, both GNOME and KDE (and I'm sure Xfce, eventually) are
planning on using systemd --user to handle the desktop session.

The normal session handling will keep working in both desktops, but
(and this is just an educated guess from my part) I think it will
happen the same as with logind: the new way to do things will work so
much better, and the other way will bitrot. Unless *someone* gives
time and code to maintain it.

>> But basically all the GNOME developers are using systemd, so the CK
>> support is getting bitrotten. That's why the Gentoo GNOME team decided
>> to depend on systemd, although the requirement is really logind.
>>
>> If *someone* creates a logind compatible replacement (it uses a simple
>> dbus API[1]), then even the GNOME suit in Gentoo could drop the
>> requirement for systemd. Ubuntu has been working on something like
>> this, and Mark Shuttleworth said that they will continue to work on
>> it, even with Ubuntu choosing systemd[2], so if/when that's available,
>> there will be no program that *requires* systemd, AFAIK.
>>
>> (Well, gnome-logs depends on the journal, but it's a GUI for a systemd
>> specific feature).
>>
>> Like I've been saying; no one is forcing nothing on no one. But
>> someone has to write/support/maintain the alternative.
>
> Excellent... so apparently, the only real new features that have any kind of
> dependency are logind and maybe journald,

systemd --user will be used at lest by GNOME and KDE.

> so all that would be needed are  compatible replacements,

Exactly. If someone is willing and able to write and support those
replacements, your non-systemd world doesn't needs to change.

> and all of the noise about systemd consuming the world has been just that... noise?

That's been my *whole* point. Nobody is forcing nothing on no one.

Now, from the point of view of a distribution, they can decide that
the supported init system is only systemd. That's their choice. That's
what Fedora, OpenSUSE and Arch did. Debian will set systemd as
*default* init, but it will keep (I suppose) supporting multiple init
systems. They need to, since the non-Linux ports will never get
systemd support. I'm pretty sure Ubuntu will switch at some point to
only support systemd.

I think Gentoo will be like Debian; we will support multiple init
systems basically forever (and Gentoo also works in FreeBSD). It's
possible the council will decide to make systemd the default init
system... in twenty or forty years.

So no, the sky isn't falling, and the systemd virus is not spreading
to touch everything you know.

However, if someone doesn't step up and provide the functionality
provided for systemd, and some projects want to use said
functionality, there will be packages that will require systemd.

You want to use those packages and not use systemd? Step in and contribute.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 1:32 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 18 Feb 2014 22:07:12 +0400, Andrew Savchenko wrote:
>
>> > Then write. Just be aware that to write a systemd profile, you need to
>> > use systemd.
>>
>> Or to create a non-systemd profile :)
>
> We already have many of those, because systemd is not the default. Part
> of making it the default, if that decision is ever taken, would be to
> modify the current profiles to support systemd, at which point the old
> versions would become the non-systemd profiles.
>
> Yes, it does take systemd users/devs to create a systemd profile, but
> they are the one that will want to use it anyway. The rest already have
> what they want.
>
> This is the way things have moved with the GNOME and KDE profiles, expect
> others to follow suit.

After seeing Andreas K. Huettel response in the other thread[1], I
think it's fine even with a systemd profile. It just sets the systemd
USE flags, mask genkernel (and dracut is so much better, IMO), mask
some USE flags (static-flags for udev, cryptsetup, and lvm2; static
for dmraid; and consolekit in general).

It's really simple; putting that on a profile or doing by hand (which
I do in my no-GNOME servers) is the same to me.

> I'm still uncomfortable with the pervasiveness of systemd, although Canek
> does put forward persuasive arguments, through a mixture of expertise and
> remaining calm.

Thanks Neil.

> So GNOME want to use logind, which may well be superior
> to ConsoleKit, but why should that require a change of init system?

Well, the logind dbus interface is available for anyone to implement
independently from systemd[2]. Ubuntu is trying to do that.

It's just that the systemd developers saw that using the features of
systemd, doing user session management was really easy, and they did.
Those systemd features are not gratuitous; that's why Ubuntu is having
trouble doing an independent replacement.

> A login daemon should be started by the init system, not be an integral
> part of it. What happens when logind no longer fulfils developers needs,
> as is the case with ConsoleKit now, how can it be replaced with an
> improved service when it is so closely tied to the init system.

Well, if that happens then they will use the support for the improved
service and logind will die like HAL or devfs.

The thing is that logind exists now, it solves real problems, and
people are using it because of that.

If someone else writes something better, I'm sure they will use that
instead. I don't see the point on worrying about what could happen
when dozens of technologies have already been tried in Linux; some
strive, and some die. Apparently, Upstart will die; it was a waste
then when RedHat choose it for RHEL 6 (or 5, I don't know, never used
it), or that Ubuntu used it?

No, lessons were learned from it. And from devfs, and OSS, and HAL.
That's how free software evolves.

It only needs people willing and able to write and maintain new cool software.

Regards.

[1] http://article.gmane.org/gmane.linux.gentoo.user/272668
[2] http://www.freedesktop.org/wiki/Software/systemd/logind/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Sebastian Beßler]

On 16.02.2014 21:56, Volker Armin Hemmann wrote:

Hello List.

> and all are linked (not compile&link) in such a manner that you can't
> just pick and choose. Oh no, you get the full treatment if you like it
> or not.

A few weeks ago I wanted to see what systemd is really like so I started
a little test and switched to systemd on my private gentoo desktop
system. I don't care what people say, if possible only my personal
experience matters.

First I thought that with systemd I have to use all the things shipped
with systemd like journald (which I don't like because I think that a
binary file for syslogs is just broken) so I looked into the config
files of systemd, deactivated journald and configured logging to rsyslog
instead. And just like journald many (if not most or even all, I'm still
at the surface of systemd configuration) of the new and ugly tools can
be replaced by the good old tools we like and love.

Out of experience I can now say that many of the point said against
systemd a just not true. Please everyone, make use of a rainy winter
evening, install a virtual maschine with an systemd distribution and
look into its options, configurations and workings. Just for the sake of
getting rid of all the little wrong statements and rumors.
Then we can concentrate on the real issues and problems of systemd.

Greetings

Sebastian Beßler

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Feb 18, 2014 3:05 PM, "Sebastian Beßler" <sebastian@darkmetatron.de>
wrote:
>
> On 16.02.2014 21:56, Volker Armin Hemmann wrote:
>
> Hello List.
>
> > and all are linked (not compile&link) in such a manner that you can't
> > just pick and choose. Oh no, you get the full treatment if you like it
> > or not.
>
> A few weeks ago I wanted to see what systemd is really like so I started
> a little test and switched to systemd on my private gentoo desktop
> system. I don't care what people say, if possible only my personal
> experience matters.
>
> First I thought that with systemd I have to use all the things shipped
> with systemd like journald (which I don't like because I think that a
> binary file for syslogs is just broken) so I looked into the config
> files of systemd, deactivated journald and configured logging to rsyslog
> instead.

In the spirit of correctness, I should mention that you don't disable the
journal; you can configure it so it doesn't stores its binary logs,  but
it's still running.

And you always can run other legacy logger alongside the journal, and have
both things; binary logs for fast retrieval, and text logs if you so desire.

> And just like journald many (if not most or even all, I'm still
> at the surface of systemd configuration) of the new and ugly tools can
> be replaced by the good old tools we like and love.
>
> Out of experience I can now say that many of the point said against
> systemd a just not true. Please everyone, make use of a rainy winter
> evening, install a virtual maschine with an systemd distribution and
> look into its options, configurations and workings. Just for the sake of
> getting rid of all the little wrong statements and rumors.
> Then we can concentrate on the real issues and problems of systemd.

Regards.

[-- Attachment #2: Type: text/html, Size: 2224 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[wabenbau]

Am Dienstag, 18.02.2014 um 14:09
schrieb Tanstaafl <tanstaafl@libertytrek.org>:

> >> I can't for the life of me think of any reason that server daemons
> >> like postfix, dovecot, apache, etc would or could ever *require*
> >> systemd.
> 
>  > Neither of those packages would ever require systemd (nor any init
>  > system). If they do, I would call that a bug.
> 
> Then why should XFCE requiring it also not be a bug?
> 
> I totally get XFCE *supporting* the use of logind, but why should it
> ever support *only* logind? That would seem insane to me.

I'm not sure if I understand you correctly but I'm using XFCE, thunar
and nautilus without systemd and everything is working fine.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 18/02/2014 23:32, Canek Peláez Valdés wrote:
> And you always can run other legacy logger alongside the journal, and
> have both things; binary logs for fast retrieval, and text logs if you
> so desire.
> 


Please do not use that phrase legacy in this context.

Classic syslogging is not legacy. It is current. The systemd method is
not the new thing that replaces and deprecates the old thing, it is
merely a new (and unproven) kid on the block.

"Legacy" in the context of logging can only really mean the old
syslogger protocol as implemented by syslogd. It has no standard behind
it and is correctly described as "whatever syslogd does", whereas there
is a new syslogging protocol, with an RFC. This is most certainly not a
legacy standard.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 18/02/2014 13:54, Mark David Dumlao wrote:
>> Shouldn't sysadmins use the init-scripts for that?
>> > If done correctly, permissions should not be an issue.
>> >
>> > Restarting services without keeping file ownership into account will
>> > always cause issues. Regardless of the init-system used.
>> >
> That's just the thing though. As a sysadmin, how do you debug a service
> that isn't starting to begin with? Let's say your new to the service. You're
> not even sure if you got the config right the first time around. Or maybe
> you're adjusting a setting somewhere, and you're confused why it
> isn't taking effect.
> 
> All the /upstream documentation/, all the /man pages/, all the /usr/share/doc
> stuff will tell you to start it _raw_. The init script obscures the
> starting options,
> environment variables, and sometimes even the running user from you. What are
> you gonna do, play a human shell script parser? Nobody's perfect, do it
> enough times and you're going to casually gloss over the line where
> --safe-mode is appended to the string depending on the phase of
> the moon...

I do all of that, I've been around long enough to have learned. Like
yourself.

ps and tailing a daemon's log file is my standard approach to really
verify that a daemon is running. The other side of the coin is I usually
start with the distro's init scripts and assume for argument sake they
work. When the facts prove that wrong, I dig deeper.

The list of daemons I use that are not well behaved wrt init scripts are
rather short in reality

> If you're lucky, you've never had to start an unfamiliar service, or debug
> someone else's unfamiliar config under time pressure...
> 

Nope, not so lucky. Not even close.

We're getting OT, but by far the worst behaved daemons out there are
non-OSS paid-for things for a corproate market. Like Ossec. Oracle
databases. Sybase. Anything and everythign that purports to do backups.
I shan't mention Oracle's various offerings for business use for fear my
brain shall explode.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 18/02/2014 14:16, J. Roeleveld wrote:
> On Tue, February 18, 2014 12:17, Alan McKinnon wrote:
>> On 18/02/2014 11:52, J. Roeleveld wrote:
>>> On Tue, February 18, 2014 10:47, Alan McKinnon wrote:
>>>> What I do run into is daemons that drop privs on start up, like
>>>> tac_plus. Unwary new sysadmins always try start/stop it as root,
>>>> causing
>>>> an unholy mess. Root the owns the log and pid files, when tac_plus
>>>> drops
>>>> privs it can't record it's state so continues to service requests but
>>>> fails to log any of them. For an auth daemon, that's a serious issue.
>>>
>>> Shouldn't sysadmins use the init-scripts for that?
>>> If done correctly, permissions should not be an issue.
>>
>> It's a little more complex than just that. It's an auth service and user
>> are frequently added, removed and modified. The daemon does syntax
>> checking on it's config file at startup or after being HUP'ed but that
>> only finds static errors. It catches things like adding people to a grop
>> instead of to a group, but misses dynamic mistakes like adding users to
>> groups that don't exist.
> 
> The auth-service gets the current state from a static file that is only
> read upon service-start?

Yes.

It's a good design for reasonably static userbases. The user details,
priviledge definitions, passwords hashes and such are stored in a single
flat file readable only by root and protected by file permissions.
Overall protection is provided by restricted shell access to the host.

We're not talking about AT&T's radius servers for dsl users here who
sign up on a web form - for that you would use a database backend - this
is for the company's network support personnel who log into the backbone
and configure the network itself. There's no rush to add new (and
unproven...) users so this scheme suits me just fine. Yes, it has quirks
but these no longer bother me myself, we get caught out by new sysadmins
who have not felt that pain yet



> 
>> It's exactly analogous to compile-time vs runtime errors, compilers
>> can't catch the latter.
>>
>> Despite this all being run out of cron with wrapper scripts to check
>> validity, automated additions and safety checks between all three
>> daemons, plus being fully documented on the internal wiki and in bold
>> blinking red caps in the login motd, people still find ways to do stuff
>> things in an attempt to fix it.
> 
> (OT: Does the bold blinking red caps work on all terminals? :) )


Um, OK, you got me there. I was exaggerating!

> 
>> The daemon also tries to log these errors, by writing to a log file it
>> has no write permissions on.
> 
> "setuid" on the group with group-write in the umask not an option?


Hmmm, that's worth investigating. I hadn't really considered that as I
have an aversion to trying to use umask as a control for anything.

> 
>> There is nothing I can do about the quality of sysadmins, I have no
>> input into the HR process and damagement think cheaper is always better,
>> including skills. What I can do, is find ways to make the software more
>> resistant to errors than it already is.
> 
> And only grant access permissions to these rookies once they have proven
> they understand rule #1: If In Doubt, Call Someone Who Knows!

Hah! I fought that good fight for years and fought it well. They don't
call me the sysadmin from hell around here without good reason. And I
did manage to get a cowboy network under control and instill respect for
how much breakage Cisco's products can cause.

It's getting harder to grant access based purely on expertise,
especially when someone crunched the numbers. It turns out that the cost
of fixing mistakes is far less than the cost of leaving new untrained
people unutilized and have support tickets pile up...

> 
> But yes, I fully understand the methods of HR and Damagement.
> It is a financial mistake and risk not to include technical expertise
> checks in the recruitement fase for technical positions.

Interesting story:

I once had a good shouting match with a support manager about the
quality of his recruits. I demanded to know why he hired so many
clueless idiots (my exact words). This manager knows me well so he just
smiled and said "Alan, you didn't get to see the applicants we rejected.
These are the best in the market who applied".

*That* was a wake-up call of note :-)


> 
> How much does it cost the company each time this goes wrong and someone
> like you has to come online to fix the issue?
> That is what Damagement needs to understand.

Surprisingly, it's not too expensive. There's always one of us on duty
or standby and outages don't continue unnoticed for long. Longest that I
recall is 3 minutes, then the phone starts ringing non-stop. remember,
this system is internal, it does not service customers.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 18, 2014 at 4:35 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 18/02/2014 23:32, Canek Peláez Valdés wrote:
>> And you always can run other legacy logger alongside the journal, and
>> have both things; binary logs for fast retrieval, and text logs if you
>> so desire.
>
> Please do not use that phrase legacy in this context.

I apologize. I did not intended to use "legacy" as a pejorative term.
I use rsyslog myself in some servers.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote:
> On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
>> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>>>> Yet again, I respect ones right to use whatever one wants, but I ask
>>>> to respect mine as well. That's why I propose a separate systemd
>>>> profile for those willing to use it.
>>>
>>> Then write. Just be aware that to write a systemd profile, you need to
>>> use systemd.
>>
>> Or to create a non-systemd profile :)
> 
> That's the best response I've read in, like, many years. That's
> perfect; I'm 100% behind it. I even volunteer to help (with testing)
> to anyone going for this.
> 
> You guys create a systemd-sucks-we-dont-want-it profile, and I promise
> to give you guys a hand.
> 
> Make a profile that "frees" users from using systemd, and I think even
> several Gentoo developers will get behind that.
> 
> Now we are talking; this has been my whole point the whole time.
> Everybody that don't want to use systemd; help this idea, and if there
> are enough of you, you'll pulled through.
> 
> Regards.
> 

For such a profile to be legitimate, systemd would have to be chosen as
the default. Gentoo is one of the last bastions of choice available to
GNU/Linux users and it would create a complete shitstorm if systemd were
pushed on Gentoo's users. You're just trying to push systemd on one of
the few distros that doesn't use it by default. Do you hang out with
John Paul Adrian Glaubitz? He's a Debian developer who has a
long-running history of pushing systemd as well. There is nothing wrong
with systemd as a choice, but to push it as the default is ridiculous.
systemd can have its own profile while the rest of the world goes on
without it. Everybody wins.

For all this talk about technical details, nobody seems to notice the
marketing that's going on and frankly it disgusts me.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Wed, February 19, 2014 00:06, Alan McKinnon wrote:
> On 18/02/2014 14:16, J. Roeleveld wrote:
>> On Tue, February 18, 2014 12:17, Alan McKinnon wrote:
>>> It's a little more complex than just that. It's an auth service and
>>> user
>>> are frequently added, removed and modified. The daemon does syntax
>>> checking on it's config file at startup or after being HUP'ed but that
>>> only finds static errors. It catches things like adding people to a
>>> grop
>>> instead of to a group, but misses dynamic mistakes like adding users to
>>> groups that don't exist.
>>
>> The auth-service gets the current state from a static file that is only
>> read upon service-start?
>
> Yes.
>
> It's a good design for reasonably static userbases. The user details,
> priviledge definitions, passwords hashes and such are stored in a single
> flat file readable only by root and protected by file permissions.
> Overall protection is provided by restricted shell access to the host.

True, then again, I use ldap for the user accounts at home.
Allows my wife to change her own password and I can quickly add an account
in case someone needs access.

> We're not talking about AT&T's radius servers for dsl users here who
> sign up on a web form - for that you would use a database backend - this
> is for the company's network support personnel who log into the backbone
> and configure the network itself. There's no rush to add new (and
> unproven...) users so this scheme suits me just fine. Yes, it has quirks
> but these no longer bother me myself, we get caught out by new sysadmins
> who have not felt that pain yet

Show them a blood-stained (ok, some dark red paint) stick when they start.
Then tell them it's used when they kill that service? ;)

>>> Despite this all being run out of cron with wrapper scripts to check
>>> validity, automated additions and safety checks between all three
>>> daemons, plus being fully documented on the internal wiki and in bold
>>> blinking red caps in the login motd, people still find ways to do stuff
>>> things in an attempt to fix it.
>>
>> (OT: Does the bold blinking red caps work on all terminals? :) )
>
>
> Um, OK, you got me there. I was exaggerating!

Too bad, I could use that on one of my machines :)

>>> The daemon also tries to log these errors, by writing to a log file it
>>> has no write permissions on.
>>
>> "setuid" on the group with group-write in the umask not an option?
>
> Hmmm, that's worth investigating. I hadn't really considered that as I
> have an aversion to trying to use umask as a control for anything.

Same here, but that could work.
Then again, I believe setuid on the folder does the same on some OSs. (Not
Linux though)

>>> There is nothing I can do about the quality of sysadmins, I have no
>>> input into the HR process and damagement think cheaper is always
>>> better,
>>> including skills. What I can do, is find ways to make the software more
>>> resistant to errors than it already is.
>>
>> And only grant access permissions to these rookies once they have proven
>> they understand rule #1: If In Doubt, Call Someone Who Knows!
>
> Hah! I fought that good fight for years and fought it well. They don't
> call me the sysadmin from hell around here without good reason. And I
> did manage to get a cowboy network under control and instill respect for
> how much breakage Cisco's products can cause.
>
> It's getting harder to grant access based purely on expertise,
> especially when someone crunched the numbers. It turns out that the cost
> of fixing mistakes is far less than the cost of leaving new untrained
> people unutilized and have support tickets pile up...

True, unfortunately...
Then again, a core of really good people can be the better option. But
then you end up becoming overly dependent on that group.

>> But yes, I fully understand the methods of HR and Damagement.
>> It is a financial mistake and risk not to include technical expertise
>> checks in the recruitement fase for technical positions.
>
> Interesting story:
>
> I once had a good shouting match with a support manager about the
> quality of his recruits. I demanded to know why he hired so many
> clueless idiots (my exact words). This manager knows me well so he just
> smiled and said "Alan, you didn't get to see the applicants we rejected.
> These are the best in the market who applied".
>
> *That* was a wake-up call of note :-)

Either done during the "boom" of IT, or wrong recruitment tactics.

>> How much does it cost the company each time this goes wrong and someone
>> like you has to come online to fix the issue?
>> That is what Damagement needs to understand.
>
> Surprisingly, it's not too expensive. There's always one of us on duty
> or standby and outages don't continue unnoticed for long. Longest that I
> recall is 3 minutes, then the phone starts ringing non-stop. remember,
> this system is internal, it does not service customers.

3 minutes downtime is acceptable, even for customers.
They generally first assume they are making a mistake ;)

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Wed, Feb 19, 2014 at 1:04 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote:
>> On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko <bircoph@gmail.com> wrote:
>>> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>>>>> Yet again, I respect ones right to use whatever one wants, but I ask
>>>>> to respect mine as well. That's why I propose a separate systemd
>>>>> profile for those willing to use it.
>>>>
>>>> Then write. Just be aware that to write a systemd profile, you need to
>>>> use systemd.
>>>
>>> Or to create a non-systemd profile :)
>>
>> That's the best response I've read in, like, many years. That's
>> perfect; I'm 100% behind it. I even volunteer to help (with testing)
>> to anyone going for this.
>>
>> You guys create a systemd-sucks-we-dont-want-it profile, and I promise
>> to give you guys a hand.
>>
>> Make a profile that "frees" users from using systemd, and I think even
>> several Gentoo developers will get behind that.
>>
>> Now we are talking; this has been my whole point the whole time.
>> Everybody that don't want to use systemd; help this idea, and if there
>> are enough of you, you'll pulled through.
>>
>> Regards.
>>
>
> For such a profile to be legitimate, systemd would have to be chosen as
> the default. Gentoo is one of the last bastions of choice available to
> GNU/Linux users and it would create a complete shitstorm if systemd were
> pushed on Gentoo's users. You're just trying to push systemd on one of
> the few distros that doesn't use it by default. Do you hang out with
> John Paul Adrian Glaubitz? He's a Debian developer who has a
> long-running history of pushing systemd as well. There is nothing wrong
> with systemd as a choice, but to push it as the default is ridiculous.
> systemd can have its own profile while the rest of the world goes on
> without it. Everybody wins.

For the record, and being completely honest (I've always been), at
some point, yeah, I would like for the devs to discuss the idea of
systemd as default init system. It does not depends on me though; the
devs (and the council they elect) will take such decision, and the
discussion (if it happens) will be in a long, long time.

But my (previous) push for a systemd-sucks profile was because I
sincerely believe that the burden of work should be on the ones
proposing *any* profile, and to support a systemd profile you *need*
to use systemd, and then it makes no sense that the people that *don't
want* systemd need to do the work for a systemd profile.

However, after Andreas K. Huettel pointed out (in [1]) how simple and
minimal a systemd profile actually is[2], I changed my mind. I now
wholeheartedly support a systemd profile, since is so small, that the
burden of work is basically negligible, and apparently the same
GNOME/systemd Gentoo developers are already doing it.

So, I think, everybody agrees now. Lets have a systemd profile.

(I mean, the work to have it apparently it's already done, so it does
not matter what I, or anyone here, argues about it).

> For all this talk about technical details, nobody seems to notice the
> marketing that's going on and frankly it disgusts me.

There is no marketing; no one is selling nothing.

We are just discussing different technologies and their merits (or
demerits), according to what each one of us knows/believe. It's
interesting, it's fun, we learn things (I learned about the systemd
profile in existence) and it changes absolutely nothing about Linux,
Gentoo, or the status of systemd anywhere.

To change Linux, Gentoo, or the status of systemd somewhere, people
need to contribute code, testing or documentation, not post arguments
in mailing lists. But again, it's fun (except for a couple of trolls),
so no harm is done.

Regards.

[1] http://article.gmane.org/gmane.linux.gentoo.user/272668
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 15:37, Canek Peláez Valdés wrote:
> On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld <joost@antarean.org> wrote:
>> As I do not have systemd installed on any machine, I can't check the
>> man-pages.
>
> They are online [1].

Useful, but not necessary for this discussion.

>> But, if that is the only method to get parseable text from journalctl,
>> then that is less then useless.
>
> I only put that option as tongue-in-cheek, since someone complained
> about not being able to "cat" the logs. Many more options are
> available.

I see this option as a easter-egg without any real value. How many of
these useless code-paths are implemented?
Can these be disabled at compile time?

>> I would expect an export option providing the same detail level as I
>> currently find in /var/log/messages.
>> A timestamp is a minimum required for logging system output.
>
> Everybody agrees with that; that's why the journal supports a lot of
> formatting options. From [2]:
>
<SNIPPED man-page>
>
> So you can have the default; journalctl -b | head:
>
> -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Tue 2014-02-18
> 08:28:44 CST. --
> Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is
> using 712.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
> 198.0M).
> Feb 10 09:50:37 centurion systemd-journal[371]: Runtime journal is
> using 716.0K (max 198.0M, leaving 297.1M of free 1.9G, current limit
> 198.0M).

<SNIPPED log examples>

>
> See if you can easily do that with rsyslog or syslog-ng.

Not easily, but I do not see the point, beyond as a nice gimmick.
Same question applies, can I disable these code-paths during compile-time?

I have log-parsing scripts that check for unexpected log-entries which
expect syslog-standard logs.
I do not see the need to have to spend time to change working code to be
able to handle different formats.

Additionally, the use of "tail -f" and "grep" allows me to check the logs
real-time for debugging purposes.
Having to use a seperate tool that converts some proprietary binary format
to human readable/scriptable single-line logs makes no sense.

It all sounds too much like the MS Windows Event-viewer to me.
Too many events with no usefull logging information (And I am referring to
OS-level messages as to why default services are not starting)

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
> On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <bircoph@gmail.com>
> wrote:
> [...]
>> Every decent project has QA and unit tests one way or another. But
>> the larger project is, the more bugs it has. And I do not want bugs
>> in PID 1, that's why it should be small and sound, not bloated (even
>> with some components split as separate binaries) and broken by design.
>
> Of course the larger a project is the *potential* number of bugs
> increases, but so what? With enough developers, users and testers, all
> bugs are *potentially* squashed.

Agreed, but I know of enough large projects with large development teams
and even more users that don't get the most basic bugs fixed.
Quantity is not equivalent to Quality.

>> Kernel has mature error correction infrastructure (Oops handling) and
>> much wider community.
>
> And systemd has a *much* wider community than any other init system.
> So it can handle a larger code base.

Incorrect. How many people use systemd as opposed to SysV Init?

>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>> > about 13 000 lines, systemd — about 200 000 lines.
>>>
>>> If you take into account the thousands of shell code that SysV and
>>> OpenRC need to fill the functionality of systemd, they use even more.

The shell-code is proven to work though and provided with most of the
software. Where it isn't provided, it can be easily created.
I have seen (and used) complex start-up scripts for large software
implementations which complex dependencies.
Fortunately, later versions of those software packages have fixed that
mess to a large extend, but I wonder how well systemd unit-files can work
in such an environment.
Having sockets created prior to service start will not work as components
will fail due to time-outs, leaving even a bigger mess.

>> If that code will fail, this wouldn't be critical at system level.
>> Thus scope of fatal error is limited.
>
> Also in systemd, since most of its code is not critical (again;
> logind, datetimed, localed, etc., failing, has no impact whatsoever on
> the rest of the system).

I understand the usecase for "logind", but what is the point of a daemon
to supply the time (datetimed)? Is this a full replacement for "ntpd"?
And what does "localed" do? That's configured once in the environment and
should be handled using environment variables.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On Wed, 19 Feb 2014 01:04:14 -0600, Daniel Campbell wrote:

> >> Or to create a non-systemd profile :)  

> For such a profile to be legitimate, systemd would have to be chosen as
> the default.

Quite the opposite, to have a separate systemd profile would mean that
systemd was not the default, otherwise it would be in the default
profile. Not that defaults really matter with Gentoo, you have a systemd
profile and an openrc profile, who gives a toss which is default when you
have a simple to make choice?

> Gentoo is one of the last bastions of choice available to
> GNU/Linux users and it would create a complete shitstorm if systemd were
> pushed on Gentoo's users.

How is putting systemd setting in a profile that a user has to
consciously choose to use forcing anything on anyone? Profiles are the
essence of choice but it appears you only want the choices you approve of
to be available.


-- 
Neil Bothwick

You have the capacity to learn from mistakes. You'll learn a lot today.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Wed, 19 Feb 2014 01:04:14 -0600
Daniel Campbell <lists@sporkbox.us> wrote:

> On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote:
> > On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko
> > <bircoph@gmail.com> wrote:
> >> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
> >>>> Yet again, I respect ones right to use whatever one wants, but I
> >>>> ask to respect mine as well. That's why I propose a separate
> >>>> systemd profile for those willing to use it.
> >>>
> >>> Then write. Just be aware that to write a systemd profile, you
> >>> need to use systemd.
> >>
> >> Or to create a non-systemd profile :)
> > 
> > That's the best response I've read in, like, many years. That's
> > perfect; I'm 100% behind it. I even volunteer to help (with testing)
> > to anyone going for this.
> > 
> > You guys create a systemd-sucks-we-dont-want-it profile, and I
> > promise to give you guys a hand.
> > 
> > Make a profile that "frees" users from using systemd, and I think
> > even several Gentoo developers will get behind that.
> > 
> > Now we are talking; this has been my whole point the whole time.
> > Everybody that don't want to use systemd; help this idea, and if
> > there are enough of you, you'll pulled through.
> > 
> > Regards.
> > 
> 
> For such a profile to be legitimate, systemd would have to be chosen
> as the default. Gentoo is one of the last bastions of choice
> available to GNU/Linux users and it would create a complete shitstorm
> if systemd were pushed on Gentoo's users. You're just trying to push
> systemd on one of the few distros that doesn't use it by default. Do
> you hang out with John Paul Adrian Glaubitz? He's a Debian developer
> who has a long-running history of pushing systemd as well. There is
> nothing wrong with systemd as a choice, but to push it as the default
> is ridiculous. systemd can have its own profile while the rest of the
> world goes on without it. Everybody wins.
> 
> For all this talk about technical details,
> nobody seems to notice the marketing

A few people including myself have noted it earlier.

> that's going on and frankly it disgusts me.

 And me too.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

[-- Attachment #1: Type: text/plain, Size: 4053 bytes --]

On 02/19/2014 09:06 AM, Gevisz wrote:
> On Wed, 19 Feb 2014 01:04:14 -0600
> Daniel Campbell <lists@sporkbox.us> wrote:
>
>> On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote:
>>> On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko
>>> <bircoph@gmail.com> wrote:
>>>> On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote:
>>>>>> Yet again, I respect ones right to use whatever one wants, but I
>>>>>> ask to respect mine as well. That's why I propose a separate
>>>>>> systemd profile for those willing to use it.
>>>>> Then write. Just be aware that to write a systemd profile, you
>>>>> need to use systemd.
>>>> Or to create a non-systemd profile :)
>>> That's the best response I've read in, like, many years. That's
>>> perfect; I'm 100% behind it. I even volunteer to help (with testing)
>>> to anyone going for this.
>>>
>>> You guys create a systemd-sucks-we-dont-want-it profile, and I
>>> promise to give you guys a hand.
>>>
>>> Make a profile that "frees" users from using systemd, and I think
>>> even several Gentoo developers will get behind that.
>>>
>>> Now we are talking; this has been my whole point the whole time.
>>> Everybody that don't want to use systemd; help this idea, and if
>>> there are enough of you, you'll pulled through.
>>>
>>> Regards.
>>>
>>
>>
>> For all this talk about technical details,
>> nobody seems to notice the marketing
> A few people including myself have noted it earlier.
>
>> that's going on and frankly it disgusts me.
>  And me too.
>
>
I have to confess that it does feel very evangelistic the approach from
folks pushing systemd.  perhaps it is just because for some it has been
four years of looking at new ways of doing things, whilst others are
just realising now how different it is.
I saw an interesting blog post [1] that basically tried to convince
directly gentoo devs.
it was interesting because of this comment:

<snip>
"
*Simon*
September 26, 2013 at 2:58 am
<https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/comment-page-1/#comment-756>


Yes, I think you’re dead on, there. It’s not that Gnome depends on
systemd – but it’s increasingly dependent on features that are only
provided by systemd. The example of OpenRC not behaving according to
GDM’s assumptions is a perfect illustration of that. It’s dependent not
on systemd, but on something that for practical purposes is
indistinguishable from systemd
"
</snip>

the difficulty is that without knowing what features are required but
assumed to be there it becomes very difficult to build something the has
the API that logind or others might be requiring.    an update of gnome
might require a new feature that is hot off the presses, and until it
breaks an openrc-logind system no one is aware of that requirement.  the
API does seem to be online [2], albeit updated 30days ago; i can't
comment if this is up to date enough or not.

I think the argument on the blog page is a bit disingenuous too -
essentially implying that if you want gnome then you must have logind,
and if you want logind you must supply the features supplied by systemd:
but to get a list of the features required is _your_ problem: go through
the gnome source code to find out.
these kinds of things are what folks are taking umbrage against. 

I'm also a little confused over the socket matrix feature.  I think it's
very clever to be negotiating and buffering socket and mounts to
services that need them, but I haven't seen a good technical argument as
to why this is required.  From my perspective i see it as xinet.d for
unix sockets and well, is anyone using xinet.d on a production server?  
Hopefuly someone can enlighten me?  also what happens if the socket
arbitrator dies ?

not trying to troll here, just my main point is that the communication
between systemd supporters seems to be more of an issue than the
possibility of change. 

thanks guys

[1]
https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

[2] http://www.freedesktop.org/wiki/Software/systemd/logind/

[-- Attachment #2: Type: text/html, Size: 5880 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/19/2014 03:02 AM, Neil Bothwick wrote:
> On Wed, 19 Feb 2014 01:04:14 -0600, Daniel Campbell wrote:
> 
>>>> Or to create a non-systemd profile :)
> 
>> For such a profile to be legitimate, systemd would have to be
>> chosen as the default.
> 
> Quite the opposite, to have a separate systemd profile would mean
> that systemd was not the default, otherwise it would be in the
> default profile. Not that defaults really matter with Gentoo, you
> have a systemd profile and an openrc profile, who gives a toss
> which is default when you have a simple to make choice?
> 
>> Gentoo is one of the last bastions of choice available to 
>> GNU/Linux users and it would create a complete shitstorm if
>> systemd were pushed on Gentoo's users.
> 
> How is putting systemd setting in a profile that a user has to 
> consciously choose to use forcing anything on anyone? Profiles are
> the essence of choice but it appears you only want the choices you
> approve of to be available.
> 
> 

Perhaps I didn't phrase it correctly. Logically, a "non systemd"
profile would necessitate either a systemd profile, or require the
default to already ship systemd. I hadn't considered the prior
existence of systemd profiles, which we currently have, so afaict the
issue is mostly moot.

Choices are great until the existence of other choices infringes on
mine. Profiles prevent that, so I have no problem with systemd
profiles. The problem lies with evangelists who aren't happy with
systemd being *a* choice. They want systemd to be *the* choice, *the*
default. That is what I take issue with.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBIi7AAoJEJUrb08JgYgHducH/2VLDbRimgiZ1rM404CjIDwy
nl5dCdNcu6XtXt/q5zxY9zVUyYQtGCZmZxT1s41xT0NpYlMv2mo++tASuZwI5tye
1bzjzd9wGPwYwqTgrWgfusH170zWURaTKXwvTAgzZowKR++MXr918HtDiHzIJtpR
QjSBvMHK3TXFe1dSQKwHFYqJ/uhx1sGTsKh7tDGdUIknXB0oaVSvuzZAlzy+2GMV
g4x189EVO46kuOSXkBWobFGVwbYSttADg97Wgol55NZiyKPGaqioHKJoLeUYVlCt
NR4L76APyUHXBqdfk+/9clPHOg3x7XJuo/cjluTjC2yDvezWpojEUJKgNAZ0fZ8=
=jg5F
-----END PGP SIGNATURE-----

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Tue, 18 Feb 2014 22:53:12 +0400
the <the.guard@mail.ru> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 02/18/14 17:56, Gevisz wrote:
> > On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés
> > <caneko@gmail.com> wrote:
> > 
> >> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com>
> >> wrote: [ snip ]
> >>> How can you be sure if something is "large enough" if, as you
> >>> say below, you do not care about probabilities?
> >> 
> >> By writing correct code?
> > 
> > No, by arguing that fixing bugs in a 200K line program is as easy
> > as fixing a bug in 20 10K line programs. It is just not true, just
> > the opposite.
> > 
> >>>>> SysVinit code size is about 10 000 lines of code, OpenRC
> >>>>> contains about 13 000 lines, systemd — about 200 000
> >>>>> lines.
> >>>> 
> >>>> If you take into account the thousands of shell code that
> >>>> SysV and OpenRC need to fill the functionality of systemd,
> >>>> they use even more.
> >>>> 
> >>>> Also, again, systemd have a lot of little binaries, many of
> >>>> them optional. The LOC of PID 1 is actually closer to SysV
> >>>> (although still bigger).
> >>>> 
> >>>>> Even assuming systemd code is as mature as sysvinit or
> >>>>> openrc (though I doubt this) you can calculate
> >>>>> probabilities of segfaults yourself easily.
> >>>> 
> >>>> I don't care about probabilities;
> >>> 
> >>> If you do not care (= do not now anything) about probabilities 
> >>> (and mathematics, in general), you just unable to understand 
> >>> that debugging a program with 200K lines of code take
> >>> 
> >>> 200000!/(10000!)^20
> >>> 
> >>> more time than debugging of 20 different programs with 10K
> >>> lines of code. You can try to calculate that number yourself
> >>> but I quite sure that if the latter can take, say, 20 days, the
> >>> former can take millions of years.
> >>> 
> >>> It is all the probability! Or, to be more precise,
> >>> combinatorics.
> >> 
> >> My PhD thesis (which I will defend in a few weeks) is in
> >> computer science, specifically computational geometry and
> >> combinatorics.
> > 
> > It is even more shameful for you to not understand such a simple
> > facts from elementary probability theory (which is mostly based on 
> > combinatorics).
> TBH I don't understand your estimate. Where did permutations come
> from? are you comparing all the different combinations of lines of
> code?

I just wanted to convey that, if an involved program is n times longer,
than another one, it does not, in general, true that it will take only
n times more time to find a bug. The dependence here would be nonlinear
and with much more steep growth than the linear one, just because all
the possible ways to go wrong grows proportional to permutations, not
necessary of lines but at least of some other units whose number is
roughly proportional to the number of lines. 


 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQEcBAEBCAAGBQJTA6wWAAoJEK64IL1uI2ha5nIH/iUl2VNVAabzJzRJzC29zmWg
> t7KwGcfrtx2D40N7n4yM4LB7VBmnyoQ6+Iroh/uk3S33S/YK/5igN8UfuhvV+lvU
> 85X3T3RE3oK3kURLq68bb4Ri2zLFQ8y1rQdrrUr9ABzy+F4Xfo+W4t+lLsHSQ+dY
> f4F7ByfJAHwh9OziFKh2/qwLj4z0Trv8AzZZhP8M29kTNWEWGyo5rGg8vRqm8Klm
> kHR3RvvTdV4AgYGHqxdtrO7qpB50VXZA8ihzl7lbmsBJj3pWBo1osFNWNP82yy7r
> s4hev5QrCpgOlEebtYi/noX8Vxx335SUirGCgjN/W9xhIwt3jfMqRes6zD+bi7A=
> =F5to
> -----END PGP SIGNATURE-----
> 

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

On Wed, 19 Feb 2014 04:34:35 -0600, Daniel Campbell wrote:

> > How is putting systemd setting in a profile that a user has to 
> > consciously choose to use forcing anything on anyone? Profiles are
> > the essence of choice but it appears you only want the choices you
> > approve of to be available.

> Perhaps I didn't phrase it correctly. Logically, a "non systemd"
> profile would necessitate either a systemd profile, or require the
> default to already ship systemd. I hadn't considered the prior
> existence of systemd profiles, which we currently have, so afaict the
> issue is mostly moot.

We already have non-systemd profiles. Until recently that is all we had.

> Choices are great until the existence of other choices infringes on
> mine. Profiles prevent that, so I have no problem with systemd
> profiles. The problem lies with evangelists who aren't happy with
> systemd being *a* choice. They want systemd to be *the* choice, *the*
> default. That is what I take issue with.

Why are you so concerned about the default, not that anyone in this
thread has suggested making systemd the default, not even Canek? If you
cannot use eselect profile set, Gentoo is not for you anyway? The
handbook tells you to select a profile quite early in the installation,
there is no default - portage complain loudly if you haven't chosen a
profile, so I fail to see how anyone can force systemd (or openrc for
that matter) on users when the choice must be made.

There are technical arguments for and against systemd, which is why this
thread was started, rhetoric about forcing default profiles on people
when there is no such thing as a default profile only serve to cloud the
real issues.


-- 
Neil Bothwick

System halted - hit any Microsoft employee to continue.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/19/2014 04:50 AM, Neil Bothwick wrote:
> On Wed, 19 Feb 2014 04:34:35 -0600, Daniel Campbell wrote:
> 
>>> How is putting systemd setting in a profile that a user has to
>>>  consciously choose to use forcing anything on anyone? Profiles
>>> are the essence of choice but it appears you only want the
>>> choices you approve of to be available.
> 
>> Perhaps I didn't phrase it correctly. Logically, a "non systemd" 
>> profile would necessitate either a systemd profile, or require
>> the default to already ship systemd. I hadn't considered the
>> prior existence of systemd profiles, which we currently have, so
>> afaict the issue is mostly moot.
> 
> We already have non-systemd profiles. Until recently that is all we
> had.
> 
>> Choices are great until the existence of other choices infringes
>> on mine. Profiles prevent that, so I have no problem with
>> systemd profiles. The problem lies with evangelists who aren't
>> happy with systemd being *a* choice. They want systemd to be
>> *the* choice, *the* default. That is what I take issue with.
> 
> Why are you so concerned about the default, not that anyone in
> this thread has suggested making systemd the default, not even
> Canek? If you cannot use eselect profile set, Gentoo is not for you
> anyway? The handbook tells you to select a profile quite early in
> the installation, there is no default - portage complain loudly if
> you haven't chosen a profile, so I fail to see how anyone can force
> systemd (or openrc for that matter) on users when the choice must
> be made.
> 
> There are technical arguments for and against systemd, which is why
> this thread was started, rhetoric about forcing default profiles on
> people when there is no such thing as a default profile only serve
> to cloud the real issues.
> 
> 

Ah. It's been a while since I installed Gentoo; I wasn't aware that
portage would yell at you for not choosing a profile, or that one
wasn't already set. In that case there's nothing for me to say wrt
defaults.

Insistence upon technical-only discussion is a bit dishonest imo, as
free software is more than code. Without the social practices,
community, etc, there wouldn't be free software. So I think
non-technical concerns can be relevant to discussions on a project,
especially ambitious ones that seek to greatly change the ecosystem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBI1QAAoJEJUrb08JgYgHLbwIAI9sg65uA330dpWdoZHua81q
CGnoHzmClRdToNeYI40UKt7uT4rlebVvV2/A4DCcOb/qOPy7V1yNX8Etdsk/PHGi
5fhmqIgG/pU7lLeBI1FVMJmGaPZOju/g23Ney1AknoAdSH6r3F1S4k7d95C3CgWs
VDlZpsB/q5e8bTIVfFSQZ4vj9I4cKz+ZNzDsD2oGepDGtH+66OPjF1MUBhBao/+c
rFrZcdaWOpTc0Soj6I+bdffijKldyOflzRkINo6mBaWWOlEh34A10rGDDcOnkT6L
0ioUBn+5C9/AIDbBX8uplaaT4nG0QWPg/gi/WH6swLme5X9kSUVeTYJMCqRFBkk=
=mK4M
-----END PGP SIGNATURE-----

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

On Wed, 19 Feb 2014 10:19:43 +0000 thegeezer wrote:
[...]
> >> For all this talk about technical details,
> >> nobody seems to notice the marketing
> > A few people including myself have noted it earlier.
> >
> >> that's going on and frankly it disgusts me.
> >  And me too.
> >
> >
> I have to confess that it does feel very evangelistic the approach from
> folks pushing systemd.  perhaps it is just because for some it has been
> four years of looking at new ways of doing things, whilst others are
> just realising now how different it is.
> I saw an interesting blog post [1] that basically tried to convince
> directly gentoo devs.
> it was interesting because of this comment:
> 
> <snip>
> "
> *Simon*
> September 26, 2013 at 2:58 am
> <https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/comment-page-1/#comment-756>
> 
> 
> Yes, I think you’re dead on, there. It’s not that Gnome depends on
> systemd – but it’s increasingly dependent on features that are only
> provided by systemd. The example of OpenRC not behaving according to
> GDM’s assumptions is a perfect illustration of that. It’s dependent not
> on systemd, but on something that for practical purposes is
> indistinguishable from systemd
> "
> </snip>

It looks like systemd PR agents put it quite simple: my way or the
highway. And it looks like Gentoo is the last major shelter for
freedom we have.
 
> the difficulty is that without knowing what features are required but
> assumed to be there it becomes very difficult to build something the has
> the API that logind or others might be requiring.    an update of gnome
> might require a new feature that is hot off the presses, and until it
> breaks an openrc-logind system no one is aware of that requirement.  the
> API does seem to be online [2], albeit updated 30days ago; i can't
> comment if this is up to date enough or not.
> 
> I think the argument on the blog page is a bit disingenuous too -
> essentially implying that if you want gnome then you must have logind,
> and if you want logind you must supply the features supplied by systemd:
> but to get a list of the features required is _your_ problem: go through
> the gnome source code to find out.
> these kinds of things are what folks are taking umbrage against. 
> 
> I'm also a little confused over the socket matrix feature.  I think it's
> very clever to be negotiating and buffering socket and mounts to
> services that need them, but I haven't seen a good technical argument as
> to why this is required.  From my perspective i see it as xinet.d for
> unix sockets and well, is anyone using xinet.d on a production server?  
> Hopefuly someone can enlighten me?  also what happens if the socket
> arbitrator dies ?

1. We never use xinetd on either production systems or
desktops/laptops. The only legitimate setup with xinetd I can recall
is CVS server. Though the very CVS technology is obsolete this days
(yes, I know portage tree is still using it and I'm looking forward
for git migration).

Socket activation feature is dubious at least. It looks like nobody
from its developers cared to assume that services may start not as
fast as they expect (e.g. network issues with cisco switches being
too slow to answer dhcp which may take up to several minutes). That's
why socket activation is extremely dangerous: it may cause services
to fail _on_ start. Some may just crash and will be restarted (though
not all services may be restarted after crash without manual
interaction, e.g. some DB setups may fail badly), while other may
loose some functionality and continue to work.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-19 2:04 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> For such a profile to be legitimate, systemd would have to be chosen as
> the default.

Ridiculous. Forget about Canek's rant...

This is about *choice*. Also, I would argue the *opposite of what Canek 
is saying in this last rant...

If he and other want systemd profiles, let *them* do the work of 
creating and maintaining them.

All the Gentoo Council would have to do is make this a new rule or part 
of the Gentoo Constitution or whatever guidelines govern things like this:

"In keeping with Gentoo's Official Policy of providing maximum choice to 
its user base, we hereby authorize this formal process for nominating, 
creating, and maintaining new profiles that make use of the new systemd 
init system."

And the number of profiles wouldn't even quite double. There are 16 now, 
if each and every one had a systemd counter-part, it would add 12 more.

So, as systemd users create the new profiles, instead of:

  # eselect profile list
Available profile symlink targets:
   [1]   default/linux/amd64/13.0 *
   [2]   default/linux/amd64/13.0/selinux
   [3]   default/linux/amd64/13.0/desktop
   [4]   default/linux/amd64/13.0/desktop/gnome
   [5]   default/linux/amd64/13.0/desktop/gnome/systemd
   [6]   default/linux/amd64/13.0/desktop/kde
   [7]   default/linux/amd64/13.0/desktop/kde/systemd
   [8]   default/linux/amd64/13.0/developer
   [9]   default/linux/amd64/13.0/no-multilib
   [10]  default/linux/amd64/13.0/x32
   [11]  hardened/linux/amd64
   [12]  hardened/linux/amd64/selinux
   [13]  hardened/linux/amd64/no-multilib
   [14]  hardened/linux/amd64/no-multilib/selinux
   [15]  hardened/linux/amd64/x32
   [16]  hardened/linux/uclibc/amd64

we may eventually (at worst) end up with:

  # eselect profile list
Available profile symlink targets:
   [1]   default/linux/amd64/13.0 *
   [2]   default/linux/amd64/13.0/systemd
   [3]   default/linux/amd64/13.0/selinux
   [4]   default/linux/amd64/13.0/selinux/systemd
   [5]   default/linux/amd64/13.0/desktop
   [6]   default/linux/amd64/13.0/desktop/systemd
   [7]   default/linux/amd64/13.0/desktop/gnome
   [8]   default/linux/amd64/13.0/desktop/gnome/systemd
   [9]   default/linux/amd64/13.0/desktop/kde
   [10]   default/linux/amd64/13.0/desktop/kde/systemd
   [11]   default/linux/amd64/13.0/developer
   [12]   default/linux/amd64/13.0/developer/systemd
   [13]   default/linux/amd64/13.0/no-multilib
   [14]   default/linux/amd64/13.0/no-multilib/systemd
   [15]  default/linux/amd64/13.0/x32
   [16]   default/linux/amd64/13.0/x32/systemd
   [17]  hardened/linux/amd64
   [18]   hardened/linux/amd64/systemd
   [19]  hardened/linux/amd64/selinux
   [20]   hardened/linux/amd64/selinux/system
   [21]  hardened/linux/amd64/no-multilib
   [22]   hardened/linux/amd64/no-multilib/systemd
   [23]  hardened/linux/amd64/no-multilib/selinux
   [24]   hardened/linux/amd64/no-multilib/selinux/systemd
   [25]  hardened/linux/amd64/x32
   [26]   hardened/linux/amd64/x32/systemd
   [27]  hardened/linux/uclibc/amd64
   [28]   hardened/linux/uclibc/amd64/systemd

You would also have to require package maintainers to support both 
profiles, unless the upstream package itself changed such that it would 
no longer work without systemd.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-18 4:05 PM, Sebastian Beßler <sebastian@darkmetatron.de> wrote:
> First I thought that with systemd I have to use all the things shipped
> with systemd like journald (which I don't like because I think that a
> binary file for syslogs is just broken) so I looked into the config
> files of systemd, deactivated journald and configured logging to rsyslog
> instead. And just like journald many (if not most or even all, I'm still
> at the surface of systemd configuration) of the new and ugly tools can
> be replaced by the good old tools we like and love.

Thanks Sebastian.

I had pretty much come to this same conclusion without even having tried 
systemd yet.

This, combined with the new knowledge that it is relatively trivial to 
allow peaceful co-existence for systemd users through the use of 
profiles, and that these would need to be created and maintained by 
those who want or need the equivalent systemd version of any given 
profile, now boils down to one last thing...

Getting the Gentoo Council behind this idea, and providing an officially 
supported - or maybe a better term is *mandated* - process whereby 
systemd proponents can create and then maintain new systemd versions of 
any existing profiles.

I guess maybe it is time to go open a bug about this?

I would be happy to do this, but maybe it would be better if someone who 
has much more knowledge of the inner workings of the Gentoo Council and 
whatever process governs things like this to do it?

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Sebastian Beßler]

On 19.02.2014 09:50, J. Roeleveld wrote:

> Additionally, the use of "tail -f" and "grep" allows me to check the logs
> real-time for debugging purposes.
> Having to use a seperate tool that converts some proprietary binary format
> to human readable/scriptable single-line logs makes no sense.

This is the reason why I configured systemd to disable the binary
logfile and to send everything to rsyslog (it could be any other logger)
instead.

I don't like that journald is still running in the background in this
setup and it is clearly a big negativ point on my list for this test of
systemd, but it is possible to use the old and good ways of doing things.

Greetings

Sebastian

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Wed, 19 Feb 2014 04:54:08 -0600, Daniel Campbell wrote:

> > There are technical arguments for and against systemd, which is why
> > this thread was started, rhetoric about forcing default profiles on
> > people when there is no such thing as a default profile only serve
> > to cloud the real issues.

> Insistence upon technical-only discussion is a bit dishonest imo, as
> free software is more than code. Without the social practices,
> community, etc, there wouldn't be free software. So I think
> non-technical concerns can be relevant to discussions on a project,
> especially ambitious ones that seek to greatly change the ecosystem.

Fair point, but attacks, name calling and arguments about the relevance
of analogies do nothing to help the discussion.

-- 
Neil Bothwick

Never get into fights with ugly people because they have nothing to lose.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mike Gilbert]

On Wed, Feb 19, 2014 at 7:57 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-18 4:05 PM, Sebastian Beßler <sebastian@darkmetatron.de> wrote:
>>
>> First I thought that with systemd I have to use all the things shipped
>> with systemd like journald (which I don't like because I think that a
>> binary file for syslogs is just broken) so I looked into the config
>> files of systemd, deactivated journald and configured logging to rsyslog
>> instead. And just like journald many (if not most or even all, I'm still
>> at the surface of systemd configuration) of the new and ugly tools can
>> be replaced by the good old tools we like and love.
>
>
> Thanks Sebastian.
>
> I had pretty much come to this same conclusion without even having tried
> systemd yet.
>
> This, combined with the new knowledge that it is relatively trivial to allow
> peaceful co-existence for systemd users through the use of profiles, and
> that these would need to be created and maintained by those who want or need
> the equivalent systemd version of any given profile, now boils down to one
> last thing...
>
> Getting the Gentoo Council behind this idea, and providing an officially
> supported - or maybe a better term is *mandated* - process whereby systemd
> proponents can create and then maintain new systemd versions of any existing
> profiles.

Just jumping in here as one of Gentoo's systemd maintainers: There is
no point in creating a second set of profiles just for systemd.
Profiles do not perform any magic; they just set/mask use flags and
set default values for some other ebuild variables.

The reason we do not have a full set of "systemd profiles" is because
they would serve no useful purpose; there is simply nothing to be
gained from creating them.

If I wanted to switch from systemd back openrc at this very moment, I
would do the following:

1. Unset the systemd use flag.
2. Replace sys-apps/systemd with sys-fs/udev (optional).
3. Run emerge -uDNav world

Having a separate profile does not make that process any easier.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Wed, Feb 19, 2014 at 2:50 AM, J. Roeleveld <joost@antarean.org> wrote:
> On Tue, February 18, 2014 15:37, Canek Peláez Valdés wrote:
>> On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld <joost@antarean.org> wrote:
>>> As I do not have systemd installed on any machine, I can't check the
>>> man-pages.
>>
>> They are online [1].
>
> Useful, but not necessary for this discussion.

It was just a pointer.

> I see this option as a easter-egg without any real value. How many of
> these useless code-paths are implemented?
> Can these be disabled at compile time?

That's neither here nor there; you said "I would expect an export
option providing the same detail level as I currently find in
/var/log/messages. A timestamp is a minimum required for logging
system output."; I proved to you that the journal shows timestamps and
much more, if so desired.

[ snip ]
>> See if you can easily do that with rsyslog or syslog-ng.
>
> Not easily,

That's (one of) the advantage(s) that the journal brings. BTW, I'm not
trying to convince anyone to use the journal (nor systemd); I'm just
pointing out about features.

> but I do not see the point, beyond as a nice gimmick.

Well, I *do* see a point. Many points, actually. You want the logs for
SSH, from February 12 to February 15? Done:

journalctl  --since=2014-02-12 --until=2014-02-15 -u sshd.service

No grep. No cat. No hunting logrotated logs (the journal will rotate
automatically its logs, and will search on all logs available). You
can have second-precision intervals.

Also, the binary format that the journal uses is indexed (hence the
binary part); therefore, the search is O(log n), no O(n). With a log
with a million entries, that's about 20 steps.

Perhaps it's just a gimmick to you. For me is a really usefull

> Same question applies, can I disable these code-paths during compile-time?

No you can't; if you wanted the journal to work exactly as rsyslog (or
syslog-ng), then there is no reason to use the journal. Its raison
d'être is the new features it brings.

If you don't want those features, don't use the journal.

> I have log-parsing scripts that check for unexpected log-entries which
> expect syslog-standard logs.

I used, too. The journal makes most of then unnecessary, and if I want
to, it can provide formatting of the logs in the same way that rsyslog
(or syslog-ng) does.

> I do not see the need to have to spend time to change working code to be
> able to handle different formats.

Well, I prefer it when someone does the work for me.

> Additionally, the use of "tail -f" and "grep" allows me to check the logs
> real-time for debugging purposes.

journalctl -f

Checks the logs in real time. Again, [1].

> Having to use a seperate tool that converts some proprietary binary format
> to human readable/scriptable single-line logs makes no sense.

Its not proprietary; the source code is available, you can write your
own parser if you want. The binary format is to be able to do O(log n)
searches, that's it. It's a performance optimization.

> It all sounds too much like the MS Windows Event-viewer to me.

Never used it.

> Too many events with no usefull logging information (And I am referring to
> OS-level messages as to why default services are not starting)

systemctl status apache2.service

(see [2]) will print the status of the Apache web server, and also the
last lines from the logs. You can control how many lines. You can
check also with the journal, as I showed up.

If you *want* to, everything is online.

Regards.

[1] http://www.freedesktop.org/software/systemd/man/journalctl.html
[2] http://www.freedesktop.org/software/systemd/man/systemctl.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@antarean.org> wrote:
> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:

[ snip ]

>> Of course the larger a project is the *potential* number of bugs
>> increases, but so what? With enough developers, users and testers, all
>> bugs are *potentially* squashed.
>
> Agreed, but I know of enough large projects with large development teams
> and even more users that don't get the most basic bugs fixed.
> Quantity is not equivalent to Quality.

I also agree with that. My point is that the systemd project has
enough numbers of *talented* developers to do it.

You can disagree, of course.

>> And systemd has a *much* wider community than any other init system.
>> So it can handle a larger code base.
>
> Incorrect. How many people use systemd as opposed to SysV Init?

Users? Like five thousand godzillions more.

Developers? It would not surprise me that systemd has several times
more developers that SysV ever had.

What's more, I think those developers are talented enough, to say the least.

>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>>> > about 13 000 lines, systemd — about 200 000 lines.
>>>>
>>>> If you take into account the thousands of shell code that SysV and
>>>> OpenRC need to fill the functionality of systemd, they use even more.
>
> The shell-code is proven to work though and provided with most of the
> software. Where it isn't provided, it can be easily created.
> I have seen (and used) complex start-up scripts for large software
> implementations which complex dependencies.
> Fortunately, later versions of those software packages have fixed that
> mess to a large extend, but I wonder how well systemd unit-files can work
> in such an environment.

You can read [1]. I think it provides a fair and impartial account of
how to use systemd to start a complex service (NFS, by its author).

> Having sockets created prior to service start will not work as components
> will fail due to time-outs, leaving even a bigger mess.

I could be wrong, but I believe the use of cgroups takes care of all
that. If the service fails, systemd PID 1 can reliable detect it, and
force the socket to close, and even reopen it for new connections if
so configured by the administrator.

>>> If that code will fail, this wouldn't be critical at system level.
>>> Thus scope of fatal error is limited.
>>
>> Also in systemd, since most of its code is not critical (again;
>> logind, datetimed, localed, etc., failing, has no impact whatsoever on
>> the rest of the system).
>
> I understand the usecase for "logind", but what is the point of a daemon
> to supply the time (datetimed)? Is this a full replacement for "ntpd"?
> And what does "localed" do? That's configured once in the environment and
> should be handled using environment variables.

I'm sorry, but *everything* you are asking for is in the link I gave
you that you qualified it of "not necessary for this discussion" (I
also pointed someone else to [2]). If you are really interested in the
answers, go on and read it there.

It's certainly better than hearing it from me.

Regards.

[1] http://lwn.net/Articles/584175/
[2] http://www.freedesktop.org/wiki/Software/systemd/#manualsanddocumentationforusersandadministrators
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-19 2:04 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>
>> For such a profile to be legitimate, systemd would have to be chosen as
>> the default.
>
> Ridiculous. Forget about Canek's rant...
>
> This is about *choice*. Also, I would argue the *opposite of what Canek is
> saying in this last rant...

Tanstaafl, can we please not use terms like "rants"? I'm just giving
my opinion, trying to be respectful and civil to the others
participants in this thread. I would appreciate if you do the same to
me.

> If he and other want systemd profiles, let *them* do the work of creating
> and maintaining them.

And as I said on [1], I agree; lets have a systemd profile... which
apparently it basically already exists[2].

(I snip the rest, since I don't really disagree with it).

Regards.

[1] http://article.gmane.org/gmane.linux.gentoo.user/272694
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

20.02.2014 09:24, Canek Peláez Valdés пишет:
> [ snip ]
>> but I do not see the point, beyond as a nice gimmick.
>
> Well, I *do* see a point. Many points, actually. You want the logs for
> SSH, from February 12 to February 15? Done:
>
> journalctl  --since=2014-02-12 --until=2014-02-15 -u sshd.service
>
> No grep. No cat. No hunting logrotated logs (the journal will rotate
> automatically its logs, and will search on all logs available). You
> can have second-precision intervals.
 >
> Also, the binary format that the journal uses is indexed (hence the
> binary part); therefore, the search is O(log n), no O(n). With a log
> with a million entries, that's about 20 steps.
>
> Perhaps it's just a gimmick to you. For me is a really usefull

Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) 
if really needed is easily achieved with databases.
Not using cat and grep is not something one'd boast; rather, again, a 
waste of resources to recreate already existing tools.
BTW, I wonder if anyone does really have logs with millions of lines in 
one single file, not split into files by date, service etc, so that the 
whole O(n) issue is moot.
Well, maybe it'd be nice to have a collection of log management tools 
all-in-one but beyond that I don't see any advantages of systemd-journald.

> Its raison d'être is the new features it brings.

I didn't notice any new features. It's not features that are new, but 
just a new implementation of old features in a more obtrusive way IMO.

>> Additionally, the use of "tail -f" and "grep" allows me to check the logs
>> real-time for debugging purposes.
>
> journalctl -f
>
> Checks the logs in real time. Again, [1].

Again, a brand new Wheel(c)

> systemctl status apache2.service
>
> (see [2]) will print the status of the Apache web server, and also the
> last lines from the logs. You can control how many lines. You can
> check also with the journal, as I showed up.

I believe it would be a 5-minutes job to add the capability of printing 
last N log entries for a service to `rc-service status`. Using cat, grep 
and the like. Not reinventing wheels. Not spending super-talented 
super-highly paid developers' time on doing tasks one had done about 30 
years ago. I believe, not having this option is due to its simple 
uselessness.

This way I really wonder if at some point the super talented systemd 
programmers decide that all shell tools are obsolete and every program 
should know how to index or filter or tail its output in its own, 
though, open, binary format. I can't get rid of the idea that systemd 
uses the MS Windows approach whatever you say about its open source.

-- 
Regards,
Yuri K. Shatroff

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 20/02/14, Yuri K. Shatroff wrote:

> > (see [2]) will print the status of the Apache web server, and also the
> > last lines from the logs. You can control how many lines. You can
> > check also with the journal, as I showed up.
> 
> I believe it would be a 5-minutes job to add the capability of printing 
> last N log entries for a service to `rc-service status`. Using cat, grep 

If I understand you correctly, what you're proposing is an analyzing
tool which works after-the-facts. I mean extracting the per-daemon logs
from a global log archive whereas systemd works the opposite way, AFAIU.

You solution requires per-daemon extraction rules and have to be
maintained over time. So, postponed to errors.

Definetly not a 5-minutes job.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

20.02.2014 15:33, Nicolas Sebrecht пишет:
> The 20/02/14, Yuri K. Shatroff wrote:
>
>>> (see [2]) will print the status of the Apache web server, and also the
>>> last lines from the logs. You can control how many lines. You can
>>> check also with the journal, as I showed up.
>>
>> I believe it would be a 5-minutes job to add the capability of printing
>> last N log entries for a service to `rc-service status`. Using cat, grep
>
> If I understand you correctly, what you're proposing is an analyzing
> tool which works after-the-facts.

I wasn't proposing anything. I was just supposing.

> I mean extracting the per-daemon logs
> from a global log archive whereas systemd works the opposite way, AFAIU.

What is a 'global log archive'? Do you mean a single file where all logs 
go? AFAIK you can set up syslog to log all messages into one file as 
well as per-service files. So the deal is just to extract configuration 
from syslog. Of course, if the services are using it, not keeping their 
own logs as is usually the case of apache. As a multiuser (multi-vhost) 
webserver admin I have to set up apache to log into users' home 
directories, so I even don't know how many user logs there really are. 
And I don't need to, because I've got my own global log. But a user is 
definitely more familiar with a text file he/she can download via FTP, 
than with a journalctl wrapper which he has to know how to use (and also 
be granted SSH access to use), at the least which parameters to specify, 
if at all usable in such setups.

> You solution requires per-daemon extraction rules and have to be
> maintained over time. So, postponed to errors.

I don't need such 'solutions' to non-existent problems. But if there 
were a *real* necessity to pretty-print a log's tail in service status, 
I think it would have been a matter of a proper setup (i.e. the service 
using syslog, hence a defined log format) and not a heck more complicated.

> Definetly not a 5-minutes job.

5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 12:43 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafl<tanstaafl@libertytrek.org>  wrote:
>> On 2014-02-19 2:04 AM, Daniel Campbell<lists@sporkbox.us>  wrote:
>>>
>>> For such a profile to be legitimate, systemd would have to be chosen as
>>> the default.
>>
>> Ridiculous. Forget about Canek's rant...
>>
>> This is about *choice*. Also, I would argue the *opposite of what Canek is
>> saying in this last rant...

> Tanstaafl, can we please not use terms like "rants"? I'm just giving
> my opinion, trying to be respectful and civil to the others
> participants in this thread. I would appreciate if you do the same to
> me.

Sorry, Canek, no offense was intended, but if you go back and re-read 
your 'extremely overly enthusiastic' post (this plus the content is why 
I referred to it as a 'rant'), while I agree with most everything you 
said, your primary point - that it should be the people who *don't* want 
systemd doing all of the work - was backwards, and that was what I 
wanted to point out.

So, please, don't take it as an insult. In fact you have done a very 
good job of patiently spelling out the advantages of systemd, to the 
point I'm no longer afraid of it taking over and devouring the linux world.

That said, in reality, there is (or should be) nothing inherently 
insulting about a claim that something you (or anyone) says was a 
'rant'. Pretty much everyone I know who has strong opinions on things 
like this rants all the time. Sometimes those rants have more 
value/substance than others. A good rant will provide lots of 
substantive supporting documentation backing up the claims in the rant. 
A bad rant just makes a bunch of baseless claims and/or personal attacks.

Bottom line: since Gentoo's default and primary init system is (and 
hopefully will be for a very long time) OpenRC, it is on the systemd 
folks to do the work to get systemd fully supported.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 20/02/2014 11:16, Yuri K. Shatroff wrote:
> 
> 
> 20.02.2014 09:24, Canek Peláez Valdés пишет:
>> [ snip ]
>>> but I do not see the point, beyond as a nice gimmick.
>>
>> Well, I *do* see a point. Many points, actually. You want the logs for
>> SSH, from February 12 to February 15? Done:
>>
>> journalctl  --since=2014-02-12 --until=2014-02-15 -u sshd.service
>>
>> No grep. No cat. No hunting logrotated logs (the journal will rotate
>> automatically its logs, and will search on all logs available). You
>> can have second-precision intervals.
>>
>> Also, the binary format that the journal uses is indexed (hence the
>> binary part); therefore, the search is O(log n), no O(n). With a log
>> with a million entries, that's about 20 steps.
>>
>> Perhaps it's just a gimmick to you. For me is a really usefull
> 
> Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n))
> if really needed is easily achieved with databases.
> Not using cat and grep is not something one'd boast; rather, again, a
> waste of resources to recreate already existing tools.
> BTW, I wonder if anyone does really have logs with millions of lines in
> one single file, not split into files by date, service etc, so that the
> whole O(n) issue is moot.

I have logs like that. It's not an uncommon scenario.

> Well, maybe it'd be nice to have a collection of log management tools
> all-in-one but beyond that I don't see any advantages of systemd-journald.

The immediate feature-add that syslog needs is arbitrary facilities, not
the 16 fixed ones in syslog() system call.


>> Its raison d'être is the new features it brings.
> 
> I didn't notice any new features. It's not features that are new, but
> just a new implementation of old features in a more obtrusive way IMO.
> 
>>> Additionally, the use of "tail -f" and "grep" allows me to check the
>>> logs
>>> real-time for debugging purposes.
>>
>> journalctl -f
>>
>> Checks the logs in real time. Again, [1].
> 
> Again, a brand new Wheel(c)
> 
>> systemctl status apache2.service
>>
>> (see [2]) will print the status of the Apache web server, and also the
>> last lines from the logs. You can control how many lines. You can
>> check also with the journal, as I showed up.
> 
> I believe it would be a 5-minutes job to add the capability of printing
> last N log entries for a service to `rc-service status`. Using cat, grep
> and the like. 


No, that will not work easily for all definitions of easily.

rc-something has zero control over where the logs go and no standard
method to provide "hints" to the logger. Gentoo ships syslog* configs
that basically stick everything in messages, where grepping them out is
a PITA. I usually rewrite that config more to my taste and needs and
rc-service cannot know what I did. So the idea fails at step 1 as the
code does not know where the logs are.


> Not reinventing wheels. Not spending super-talented
> super-highly paid developers' time on doing tasks one had done about 30
> years ago. I believe, not having this option is due to its simple
> uselessness.

30 years ago we had isolated stand-alone machines without nothing like
the logging needs we have today. Whilst I agree with you that systemd's
logging tools may not be the solution, I can assure you (as someone who
has to deal with this shit) that syslogging in the modern world is a mess.

Try this: Decide you cannot afford Splunk, so do it yourself. Now get
your Apache access logs into the same searchable database your other
stuff is in, and do it in such a way that you can SELECT what you want
out in obvious ways.

Repeat for every other app you have that logs stuff. Remember to find
the really important logs which are usually sitting in /opt/ and
produced by Log4Perl or something equally abominable.


> 
> This way I really wonder if at some point the super talented systemd
> programmers decide that all shell tools are obsolete and every program
> should know how to index or filter or tail its output in its own,
> though, open, binary format. I can't get rid of the idea that systemd
> uses the MS Windows approach whatever you say about its open source.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 20/02/2014 13:53, Yuri K. Shatroff wrote:
> I don't need such 'solutions' to non-existent problems. But if there
> were a *real* necessity to pretty-print a log's tail in service status,
> I think it would have been a matter of a proper setup (i.e. the service
> using syslog, hence a defined log format) and not a heck more complicated.
> 
>> Definetly not a 5-minutes job.
> 
> 5 minutes is even too much to type sort of
> tail -${LINES} ${SERVICE}.log
> if you know where to look up LINES and SERVICE.


You've never actually tried this, right?

Your idea instantly fails as the rc-service author has no idea of what
you defined ${SERVICE} to be and no way to determine what it is now.

How are you going to deal with the situation with a big busy daemon that
immediately starts serving requests when started (i.e. with very little
delay)?

By the time grep, sed, awk and friends have gotten around to making
their way through a log file of varying size, the entries that apply to
restart can easy be many hundreds of log lines prior.

I have done this, and it does not work. I got a result and it's
relaible, but you don't want to know what it took. It's also highly
customized and useless to anything other than my highly customized setup.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 3:16 AM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
>
>
> 20.02.2014 09:24, Canek Peláez Valdés пишет:
>>
>> [ snip ]
>>
>>> but I do not see the point, beyond as a nice gimmick.
>>
>>
>> Well, I *do* see a point. Many points, actually. You want the logs for
>> SSH, from February 12 to February 15? Done:
>>
>> journalctl  --since=2014-02-12 --until=2014-02-15 -u sshd.service
>>
>> No grep. No cat. No hunting logrotated logs (the journal will rotate
>> automatically its logs, and will search on all logs available). You
>> can have second-precision intervals.
>
>>
>>
>> Also, the binary format that the journal uses is indexed (hence the
>> binary part); therefore, the search is O(log n), no O(n). With a log
>> with a million entries, that's about 20 steps.
>>
>> Perhaps it's just a gimmick to you. For me is a really usefull
>
>
> Clearly, it's reinventing a wheel.

Where I come from, doing something that takes O(n) in O(log n) is nor
reinventing the wheel, but, OK, see it that way if you want to. Simply
don't use it.

> All that indexing stuff and O(log(n)) if
> really needed is easily achieved with databases.

The journal is a specialized database for logs.

> Not using cat and grep is not something one'd boast; rather, again, a waste
> of resources to recreate already existing tools.

Are those *your* resources? If not, what's the problem?

> BTW, I wonder if anyone does really have logs with millions of lines in one
> single file, not split into files by date, service etc, so that the whole
> O(n) issue is moot.

Oh boy, you haven't worked much in enterprise, right?

Also, even if *one* machine doesn't have logs with a million lines
(which I've seen it, in real life, in *production*, but whatever), the
journal can send (automatically, of course, if so configured) logs to
a central server. So you can coalesce the logs from *all* your network
in a single place, and with the journal you can merge them when doing
queries. Again, Everything in O(log n).

Si right now I have a little server with logs of ~75,000 lines. If I
had 20 (nothing weird in enterprise, may would call that a really
small operation), that would be logs of 1,500,000 lines. With the
journal, you could check *all* your servers with a single command, and
all the queries could be done in O(log n).

So, yeah, moot.

> Well, maybe it'd be nice to have a collection of log management tools
> all-in-one but beyond that I don't see any advantages of systemd-journald.

Then, again, don't use it.

>> Its raison d'être is the new features it brings.
>
>
> I didn't notice any new features. It's not features that are new, but just a
> new implementation of old features in a more obtrusive way IMO.

Again, O(n) vs. O(log n). Coalescing logs from different machines. A
single powerful tool with well define semantics to query the logs.

So, yeah, no new features.

>>> Additionally, the use of "tail -f" and "grep" allows me to check the logs
>>> real-time for debugging purposes.
>>
>>
>> journalctl -f
>>
>> Checks the logs in real time. Again, [1].
>
>
> Again, a brand new Wheel(c)

I never said that was a new feature. Roeleveld said that he could use
"tail -f" and grep, like that was not possible with the journal. I was
proving him it could be done with the journal.

>> systemctl status apache2.service
>>
>> (see [2]) will print the status of the Apache web server, and also the
>> last lines from the logs. You can control how many lines. You can
>> check also with the journal, as I showed up.
>
>
> I believe it would be a 5-minutes job to add the capability of printing last
> N log entries for a service to `rc-service status`. Using cat, grep and the
> like. Not reinventing wheels. Not spending super-talented super-highly paid
> developers' time on doing tasks one had done about 30 years ago. I believe,
> not having this option is due to its simple uselessness.

Others have chimed in on the infeasibility of this claim. However, if
you don't want to use the journal, and can emulate everything it does
in 5 minutes, then don't use the journal and write your little shell
scripts in 5 minutes.

I'd rather see cats with Wolverine claws in YouTube with those 5
minutes, and let the journal do the thing. But that's me.

> This way I really wonder if at some point the super talented systemd
> programmers decide that all shell tools are obsolete and every program
> should know how to index or filter or tail its output in its own, though,
> open, binary format. I can't get rid of the idea that systemd uses the MS
> Windows approach whatever you say about its open source.

Again, the journal can export an output (and really fast, since it has
everything indexed) that is 100% identical to the output of any other
logger. And you can use on it shell, grep and sed to your heart's
desire.

But if you don't want to, then don't use the journal. Nobody is
forcing it on you.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-20 12:43 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafl<tanstaafl@libertytrek.org>
>> wrote:
>>>
>>> On 2014-02-19 2:04 AM, Daniel Campbell<lists@sporkbox.us>  wrote:
>>>>
>>>>
>>>> For such a profile to be legitimate, systemd would have to be chosen as
>>>> the default.
>>>
>>>
>>> Ridiculous. Forget about Canek's rant...
>>>
>>> This is about *choice*. Also, I would argue the *opposite of what Canek
>>> is
>>> saying in this last rant...
>
>
>> Tanstaafl, can we please not use terms like "rants"? I'm just giving
>> my opinion, trying to be respectful and civil to the others
>> participants in this thread. I would appreciate if you do the same to
>> me.
>
>
> Sorry, Canek, no offense was intended, but if you go back and re-read your
> 'extremely overly enthusiastic' post (this plus the content is why I
> referred to it as a 'rant'),

Thanks for the explanation.

> while I agree with most everything you said,
> your primary point - that it should be the people who *don't* want systemd
> doing all of the work - was backwards, and that was what I wanted to point
> out.

I still believe that a non-systemd profile should be done by the
people not wanting to use systemd. But since I now support the systemd
profile (since it's trivial) the point is moot.

> So, please, don't take it as an insult. In fact you have done a very good
> job of patiently spelling out the advantages of systemd, to the point I'm no
> longer afraid of it taking over and devouring the linux world.

Thanks.

> That said, in reality, there is (or should be) nothing inherently insulting
> about a claim that something you (or anyone) says was a 'rant'. Pretty much
> everyone I know who has strong opinions on things like this rants all the
> time. Sometimes those rants have more value/substance than others. A good
> rant will provide lots of substantive supporting documentation backing up
> the claims in the rant. A bad rant just makes a bunch of baseless claims
> and/or personal attacks.

I don't think I was shouting (which I believe is part of the "rant"
definition); but whatever, I now understand you didn't mean any harm
and I appreciate it.

> Bottom line: since Gentoo's default and primary init system is (and
> hopefully will be for a very long time) OpenRC, it is on the systemd folks
> to do the work to get systemd fully supported.

Which has been the case up until now.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 10:55 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> while I agree with most everything you said, your primary point -
>> that it should be the people who *don't* want systemd doing all of
>> the work - was backwards, and that was what I wanted to point out.

> I still believe that a non-systemd profile should be done by the
> people not wanting to use systemd. But since I now support the systemd
> profile (since it's trivial) the point is moot.

<snip>

>> Bottom line: since Gentoo's default and primary init system is (and
>> hopefully will be for a very long time) OpenRC, it is on the systemd folks
>> to do the work to get systemd fully supported.

> Which has been the case up until now.

As you have freely admitted that OpenRC being the default init system 
for gentoo is unlikely to change anytime soon, I'm at a loss as to how 
you can justify your first comment above? Your comment would only make 
sense if systemd was made the default init system.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 12:18 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-20 10:55 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl <tanstaafl@libertytrek.org>
>> wrote:
>>>
>>> while I agree with most everything you said, your primary point -
>>> that it should be the people who *don't* want systemd doing all of
>>> the work - was backwards, and that was what I wanted to point out.
>
>
>> I still believe that a non-systemd profile should be done by the
>> people not wanting to use systemd. But since I now support the systemd
>> profile (since it's trivial) the point is moot.
>
>
> <snip>
>
>
>>> Bottom line: since Gentoo's default and primary init system is (and
>>> hopefully will be for a very long time) OpenRC, it is on the systemd
>>> folks
>>> to do the work to get systemd fully supported.
>
>
>> Which has been the case up until now.
>
>
> As you have freely admitted that OpenRC being the default init system for
> gentoo is unlikely to change anytime soon, I'm at a loss as to how you can
> justify your first comment above? Your comment would only make sense if
> systemd was made the default init system.

OK, I think I get the misunderstanding. This is how I saw the discussion:

1. Some people started to say that systemd should go on its own
profile. The people saying that DID NOT wanted to use systemd.
2. I thought that the people using systemd were not interested in
making a systemd profile (I was wrong, the profile basically already
exists).
3. Since you cannot FORCE no one to work on something, then the burden
of work of this systemd profile would have landed on the people NOT
WANTING to use systemd. To me, this does not make sense.
4. When someone (don't remember whom) proposed a systemd-sucks
profile, I thought that was perfect, because the burden of work then
would have landed on the people that want this profile. I even
volunteered to help.
5. The moment I saw that the profile is already done, I changed my
mind; the people using systemd ALREADY did the work (which seems to be
trivial, BTW; I didn't knew that either), therefore no one is trying
forcing anyone to do work, then a systemd profile is fine (since it's
already done).

This is orthogonal to which init system is the default, I think. I was
just arguing that if a group A of people want a profile X, that group
A of people must do the work to get said profile X working. In the
case of systemd, that means *using* systemd, so it made no sense to me
that the group A did the work, when they *do not* want to use systemd.

Once again, all of this is made moot by the fact that the systemd
profile is basically available now. But that does not change my point
that if someone wants a X profile, then the burden of work must fall
on that someone.

Clear now?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 1:36 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> The moment I saw that the profile is already done, I changed my
> mind; the people using systemd ALREADY did the work (which seems to be
> trivial, BTW; I didn't knew that either), therefore no one is trying
> forcing anyone to do work, then a systemd profile is fine (since it's
> already done).

Well, sort of... there are currently only two systemd profiles (gnome 
and kde).

Is someone wants to use systemd with any of the other predefined 
profiles, ie:

default/linux/amd64/13.0

then their current choice is to change to systemd manually (which as you 
and others have pointed out doesn't seem to be that big a deal), or, if 
they wanted to make it easier for anyone/everyone else (which, I 
believe, as a systemd proponent, you would be in favor of) to choose 
systemd at install time, they could do the work of creating a new 
systemd version of each of the other profiles.

Hmmm...

Thinking about this more, since apparently using a separate profile may 
just be 'overkill', how about something simpler, like, for example, 
using eselect...

Something like:

  # eselect init list
Available init systems:
   [1]   OpenRC *
   [2]   systemd
   [3]   runit

(whatever choices are supported).

Or am I just being ridiculous?

> This is orthogonal to which init system is the default, I think.

No, actually, I think whatever is defined as the current default should 
dictate which group should be required to do the work.

> I was just arguing that if a group A of people want a profile X, that
> group A of people must do the work to get said profile X working. In
> the case of systemd, that means *using* systemd, so it made no sense
> to me that the group A did the work, when they *do not* want to use
> systemd.

?

If Group A wants to be able to easily use systemd in gentoo, then Group 
A people must get together and create systemd version of all of the 
profiles they want to be able to use systemd with... ie, if they want a 
hardened amd64 systemd profile, they would have to create one.

> Once again, all of this is made moot by the fact that the systemd
> profile is basically available now. But that does not change my point
> that if someone wants a X profile, then the burden of work must fall
> on that someone.

I agree... but since OpenRC is the default init system for gentoo, and 
certain people want to make it easier for people to install and/or 
switch to systemd in gentoo, then it is on *those* people to do the work.

I'm still not sure why we are still discussing this... ;)

Maybe a language thing?

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 4960 bytes --]

On Thu, Feb 20, 2014 at 2:06 PM, Tanstaafl <tanstaafl@libertytrek.org>
wrote:
> On 2014-02-20 1:36 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> The moment I saw that the profile is already done, I changed my
>> mind; the people using systemd ALREADY did the work (which seems to be
>> trivial, BTW; I didn't knew that either), therefore no one is trying
>> forcing anyone to do work, then a systemd profile is fine (since it's
>> already done).
>
>
> Well, sort of... there are currently only two systemd profiles (gnome and
> kde).

No, the link [1] that Andreas K. Huettel posted in [2] (which I believe you
never saw) *IS* basically all you need for a systemd "profile".

It's, almost literally, *nothing*.

> Is someone wants to use systemd with any of the other predefined profiles,
> ie:
>
> default/linux/amd64/13.0
>
> then their current choice is to change to systemd manually (which as you
and
> others have pointed out doesn't seem to be that big a deal), or, if they
> wanted to make it easier for anyone/everyone else (which, I believe, as a
> systemd proponent, you would be in favor of) to choose systemd at install
> time, they could do the work of creating a new systemd version of each of
> the other profiles.
>
> Hmmm...
>
> Thinking about this more, since apparently using a separate profile may
just
> be 'overkill', how about something simpler, like, for example, using
> eselect...
>
> Something like:
>
> # eselect init list
> Available init systems:
> [1] OpenRC *
> [2] systemd
> [3] runit
>
> (whatever choices are supported).
>
> Or am I just being ridiculous?

No, yo are not; but the switching requires reemerging things because you
need to set some USE flags and quit others. That's the "difficult" (which
is not, really) part; if you set the USE flags yourself or via a profile,
or an eselect module, I don't think the difference matters at all.

>> This is orthogonal to which init system is the default, I think.
>
> No, actually, I think whatever is defined as the current default should
> dictate which group should be required to do the work.

I think this is where we think differently (regarding this particular
point). The work must be done by *whomever* wants to do the job. So if the
systemd people want to do a profile that's fine (and this already
happened); but if they don't want to, nobody can force them to do it (this
is academic right now, since they already did the [pretty trivial] work).

If the systemd people did not wanted to do the job, then, since you can't
force them, the people *not* wanting systemd would be the ones required to
do it. And that makes absolutely no sense.

Again, this is all moot since the profile already exists. And even without
a profile, the change is easy enough.

>> I was just arguing that if a group A of people want a profile X, that
>> group A of people must do the work to get said profile X working. In
>> the case of systemd, that means *using* systemd, so it made no sense
>> to me that the group A did the work, when they *do not* want to use
>> systemd.
>
>
> ?
>
> If Group A wants to be able to easily use systemd in gentoo, then Group A
> people must get together and create systemd version of all of the profiles
> they want to be able to use systemd with... ie, if they want a hardened
> amd64 systemd profile, they would have to create one.

That's the failing in your logic (IMO); if group A wants systemd, they
already got it. No profile would make it easier (since reemerging stuff
will still be necessary), so we don't really need it. Even so, such a
profile (or "candidate" for a profile, if you desire to call it that way)
already exists.

But if nobody wants to do a systemd "proper" profile, that's fine, and
nobody will force no one to write it.

>> Once again, all of this is made moot by the fact that the systemd
>> profile is basically available now. But that does not change my point
>> that if someone wants a X profile, then the burden of work must fall
>> on that someone.
>
> I agree... but since OpenRC is the default init system for gentoo, and
> certain people want to make it easier for people to install and/or switch
to
> systemd in gentoo, then it is on *those* people to do the work.

If someone willing and able wants to do the work, it will be done. If
nobody wants to do the work, the work will not get done. Business as usual
in Gentoo and Linux.

> I'm still not sure why we are still discussing this... ;)

Just some different views on how the work gets done, I think.

> Maybe a language thing?

Possibly.

Regards.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/
[2] http://article.gmane.org/gmane.linux.gentoo.user/272668
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 6121 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> No, actually, I think whatever is defined as the current default should
>> dictate which group should be required to do the work.

> I think this is where we think differently (regarding this particular
> point). The work must be done by *whomever* wants to do the job. So if
> the systemd people want to do a profile that's fine (and this already
> happened); but if they don't want to, nobody can force them to do it
> (this is academic right now, since they already did the [pretty trivial]
> work).
>
> If the systemd people did not wanted to do the job, then, since you
> can't force them, the people *not* wanting systemd would be the ones
> required to do it. And that makes absolutely no sense.

I think we agree, but you keep saying we don't... ;)

The difference is, since OpenRC is the default, all of the existing 
profiles are, by definition, OpenRC based profiles. So, people who don't 
want systemd simply have to do... nothing!

As I said before, it is people who want systemd who currently have to 
'do something', and that is as it should be, unless/until the default of 
OpenRC is changed to systemd.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>
>>> No, actually, I think whatever is defined as the current default should
>>> dictate which group should be required to do the work.
>
>
>> I think this is where we think differently (regarding this particular
>> point). The work must be done by *whomever* wants to do the job. So if
>> the systemd people want to do a profile that's fine (and this already
>> happened); but if they don't want to, nobody can force them to do it
>> (this is academic right now, since they already did the [pretty trivial]
>> work).
>>
>> If the systemd people did not wanted to do the job, then, since you
>> can't force them, the people *not* wanting systemd would be the ones
>> required to do it. And that makes absolutely no sense.
>
>
> I think we agree, but you keep saying we don't... ;)
>
> The difference is, since OpenRC is the default, all of the existing profiles
> are, by definition, OpenRC based profiles. So, people who don't want systemd
> simply have to do... nothing!

OK, I see your point.

> As I said before, it is people who want systemd who currently have to 'do
> something', and that is as it should be, unless/until the default of OpenRC
> is changed to systemd.

Agreed.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Michael Higgins]

On Thu, 20 Feb 2014 15:38:46 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl
> <tanstaafl@libertytrek.org> wrote:
> > On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> >>>
> >>> No, actually, I think whatever is defined as the current default
> >>> should dictate which group should be required to do the work.
> >
> >
> >> I think this is where we think differently (regarding this
> >> particular point). The work must be done by *whomever* wants to do
> >> the job. So if the systemd people want to do a profile that's fine
> >> (and this already happened); but if they don't want to, nobody can
> >> force them to do it (this is academic right now, since they
> >> already did the [pretty trivial] work).
> >>
> >> If the systemd people did not wanted to do the job, then, since you
> >> can't force them, the people *not* wanting systemd would be the
> >> ones required to do it. And that makes absolutely no sense.
> >
> >
> > I think we agree, but you keep saying we don't... ;)
> >
> > The difference is, since OpenRC is the default, all of the existing
> > profiles are, by definition, OpenRC based profiles. So, people who
> > don't want systemd simply have to do... nothing!
> 
> OK, I see your point.
> 
> > As I said before, it is people who want systemd who currently have
> > to 'do something', and that is as it should be, unless/until the
> > default of OpenRC is changed to systemd.
> 
> Agreed.
> 
> Regards.

Been following along, jumping in late.

That does settle the issue with regard to Gentoo 'defaults' for now. As
I see it, if you are a desktop [l]user, then go ahead and use a quick
systemd default. It's good enough. And Gnome folks, from what I
understood, didn't have an easy opt-out choice, really. At least not
easy enough for me to grok right away.

Anyway, some arguments on the other branches of this thread got me
thinking. Take the binary log files. This seems to be something we all
understand to some extent (as compared to init systems, say), whether
a tinkerer or enterprise user. There's now something corporate sitting
between me and the evil crap coming out of my daemons.

Who logs the loggers?

My thought was, well, say if someone else, some other, unrelated team
entirely, was maintaining a codebase for handling that logging data,
that's a way out of the monoculture of systemd that would give some
peace of mind. If they, as also smart, talented coders began to
disagree, they might have capacity to keep the project in bounds.

So, for the hell of it, I just went to have a look at what the deal
might be with that binary data that hangs around and dumps to disk,
maybe, in one format or another.

"This document explains the basic structure of the file format on disk.
We are making this available primarily to allow review and provide
documentation. Note that the actual implementation in the systemd
codebase is the only ultimately authoritative description of the
format, so if this document and the code disagree, the code is right.
That said we'll of course try hard to keep this document up-to-date and
accurate.

Instead of implementing your own reader or writer for journal files we
ask you to use the Journal's native C API to access these files. It
provides you with full access to the files, and will not withhold any
data. If you find a limitation, please ping us and we might add some
additional interfaces for you."

From:

http://www.freedesktop.org/wiki/Software/systemd/journal-files/

Wow, that makes me feel all warm, fuzzy and secure as shit. I think I
just fell asleep for a moment. (My background would make me read this,
essentially advertising copy, as a classic example of perverse use of
semiotics, thus raising the reading on my B.S. meter. But I digress.)

The best part is the conclusion:

*If you find a limitation, please ping us and we might add some
additional interfaces for you.*

Please! Ping!

Second best is, "we'll of course try hard to keep this document
up-to-date and accurate". Of course.

So. If I were paranoid, or even mildly concerned, I'd take this to mean
two things:

One. There is, or could be, data that the systemd logging magic box
doesn't give you an interface for. Unless you know what it is, then
they might let you log it. Or you can, of course, contribute code, I'm
sure. Though, "Note that the actual implementation in the systemd
codebase is the only ultimately authoritative description of the
format".

Two. If I want to have a reasonable degree of surety that the code
isn't collecting data that isn't interfaced for you in the
journalcontrol, I'd have to delve into the codebase for systemd. Which,
I'm sure, is a piece of cake. And, of course, I, and my security team,
have to review the basic code on my GNU/Linux F[L]OSS machine regularly
anyway.

Oh, wait... No I don't. 

The beauty of the development model I trust is a diverse group of folks
with a *variety of interests* contributing to various areas of code, in
turn reviewed by some set of that same varied group, eventually
committed and merged rolled tested in the wild.

Or however you may see the ideal (or fantasy) of the ecosystem as we
know, or knew it.

Just the comment in this other related thread, systemd deprecating a
straightforward encryption setup in version N, what is next?

Okay, I'll go re-wire my tin hat now. Hope someone found this amusing.

Cheers,

- mykhyggz

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/15/2014 08:09 PM, walt wrote:
> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
>> The social
>> tactics at work from the systemd team (and verily, other Red Hat
>> projects like GNOME) are reminiscent of Microsoft through the use of the
>> "Embrace, Extend, Extinguish" methodology.
> 
> I certainly share your hostility towards M$ for suppressing competition.
> 
> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
> that they want to suppress their competitors (though I don't know who
> their competitors are).
> 
> But comparing a completely closed-source shop like M$ to any open source
> company leaves me feeling uneasy.  I can't find the exact argument to
> explain my unease, but I'm hoping someone else will jump in with a more
> rational argument.
>  
> 
> 

I think I understand where you're coming from. "How can they compare
when Red Hat releases their source under a liberating license while MS
locks it down behind closed doors?"

That's missing the point, though. In the FOSS world, that's the "bait",
so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
on) a bunch of attractive software or features, get people interested
(so interested that, say, the majority of distros depend on it *wink
wink*), and then use that influence to indirectly control where FOSS
moves. By striking the weakest part of the stack (sysv probably *did*
need a good replacement, but not one as ambitious as systemd) and
digging down into the kernel level (kdbus), Red Hat devs will now have a
very influential role in the FOSS world. This will in turn generate
interest (and thus profit) in Red Hat.

It's marginally clever, but so clearly obvious at the same time. It's
sad (to me) that the community didn't see it coming. Those who did have
been written off as conspiracy theorists or FUDders. Time will reveal all.

~Daniel

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Michael Higgins]

On Thu, 20 Feb 2014 15:37:09 -0800
Michael Higgins <linux@evolone.org> wrote:


> Okay, I'll go re-wire my tin hat now. Hope someone found this amusing.

One other thought I'd has was, well, as long as systemd doesn't, like,
implement some kind of net protocol, so to make it possible to ship
logs from systemdjournalcontrol. 

I mean, so what if then it just sits there doing its job, more or less.
You can even offload the job to your favourite logger, and it just sits
there, pretty much inoffensively in the pid 1 family.

Then I read this:

"I am curently working on getting log syncing via both a PUSH and PULL
model done. This will be based one existing protocols and standards as
much as we can (SSH or HTTP/HTTPS as transport, and JSON and more as
payload), and is flexible for others to hook into. For example, I think
it would be cool if greylog2 and similar software would just pull the
data out of the journal on its own, simply via HTTP/JSON. We make
everything available to make this smooth, i.e. we provide clients with
stable cursors which they can use to restart operation."

So, I don't know. That 'journalctl' seems to be really just a front-end
to some routines actuall coded in sytemd. So, I guess, windows all over
again? Really, a net protocol at that level? I'm sure there's no way to
exploit that.

What I do know is, that if any point I work again in IT, it will just
be part of "the way it is done", for the same reasons most shops don't
use Gentoo, for example. No one will blame you for using whatever, if
pretty much everyone else does so too. Plus, if there's some massive
codebase with a flaw causing a security breach, you're not alone.

But, seriously, flawed (carnivorous or nefarious) by design does seem to
be the upshot here, the more I read about the design decisions.

I don't think I've presented any compelling argument against anyone
else using it, per se, more than questioning the logic of it becoming
ubiquitous. It does seem to solve a lot of "real world" problems, in
one way, or another.

And I'm done looking at it, I think, and will leave it to others to
take my notes with the grains of salt required. For me, I don't really
have a need for what it offers, nor a "real world" need to worry about
possible implications of its design or rate of adoption.

Cheers,

> Cheers,
> 
> - mykhyggz
> 

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 5:37 PM, Michael Higgins <linux@evolone.org> wrote:
> On Thu, 20 Feb 2014 15:38:46 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
>> On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl
>> <tanstaafl@libertytrek.org> wrote:
>> > On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >>>
>> >>> No, actually, I think whatever is defined as the current default
>> >>> should dictate which group should be required to do the work.
>> >
>> >
>> >> I think this is where we think differently (regarding this
>> >> particular point). The work must be done by *whomever* wants to do
>> >> the job. So if the systemd people want to do a profile that's fine
>> >> (and this already happened); but if they don't want to, nobody can
>> >> force them to do it (this is academic right now, since they
>> >> already did the [pretty trivial] work).
>> >>
>> >> If the systemd people did not wanted to do the job, then, since you
>> >> can't force them, the people *not* wanting systemd would be the
>> >> ones required to do it. And that makes absolutely no sense.
>> >
>> >
>> > I think we agree, but you keep saying we don't... ;)
>> >
>> > The difference is, since OpenRC is the default, all of the existing
>> > profiles are, by definition, OpenRC based profiles. So, people who
>> > don't want systemd simply have to do... nothing!
>>
>> OK, I see your point.
>>
>> > As I said before, it is people who want systemd who currently have
>> > to 'do something', and that is as it should be, unless/until the
>> > default of OpenRC is changed to systemd.
>>
>> Agreed.
>>
>> Regards.
>
> Been following along, jumping in late.
>
> That does settle the issue with regard to Gentoo 'defaults' for now. As
> I see it, if you are a desktop [l]user, then go ahead and use a quick
> systemd default. It's good enough. And Gnome folks, from what I
> understood, didn't have an easy opt-out choice, really. At least not
> easy enough for me to grok right away.
>
> Anyway, some arguments on the other branches of this thread got me
> thinking. Take the binary log files. This seems to be something we all
> understand to some extent (as compared to init systems, say), whether
> a tinkerer or enterprise user. There's now something corporate sitting
> between me and the evil crap coming out of my daemons.
>
> Who logs the loggers?
>
> My thought was, well, say if someone else, some other, unrelated team
> entirely, was maintaining a codebase for handling that logging data,
> that's a way out of the monoculture of systemd that would give some
> peace of mind. If they, as also smart, talented coders began to
> disagree, they might have capacity to keep the project in bounds.
>
> So, for the hell of it, I just went to have a look at what the deal
> might be with that binary data that hangs around and dumps to disk,
> maybe, in one format or another.
>
> "This document explains the basic structure of the file format on disk.
> We are making this available primarily to allow review and provide
> documentation. Note that the actual implementation in the systemd
> codebase is the only ultimately authoritative description of the
> format, so if this document and the code disagree, the code is right.
> That said we'll of course try hard to keep this document up-to-date and
> accurate.
>
> Instead of implementing your own reader or writer for journal files we
> ask you to use the Journal's native C API to access these files. It
> provides you with full access to the files, and will not withhold any
> data. If you find a limitation, please ping us and we might add some
> additional interfaces for you."
>
> From:
>
> http://www.freedesktop.org/wiki/Software/systemd/journal-files/
>
> Wow, that makes me feel all warm, fuzzy and secure as shit. I think I
> just fell asleep for a moment. (My background would make me read this,
> essentially advertising copy, as a classic example of perverse use of
> semiotics, thus raising the reading on my B.S. meter. But I digress.)
>
> The best part is the conclusion:
>
> *If you find a limitation, please ping us and we might add some
> additional interfaces for you.*
>
> Please! Ping!
>
> Second best is, "we'll of course try hard to keep this document
> up-to-date and accurate". Of course.
>
> So. If I were paranoid, or even mildly concerned, I'd take this to mean
> two things:
>
> One. There is, or could be, data that the systemd logging magic box
> doesn't give you an interface for. Unless you know what it is, then
> they might let you log it. Or you can, of course, contribute code, I'm
> sure. Though, "Note that the actual implementation in the systemd
> codebase is the only ultimately authoritative description of the
> format".
>
> Two. If I want to have a reasonable degree of surety that the code
> isn't collecting data that isn't interfaced for you in the
> journalcontrol, I'd have to delve into the codebase for systemd. Which,
> I'm sure, is a piece of cake. And, of course, I, and my security team,
> have to review the basic code on my GNU/Linux F[L]OSS machine regularly
> anyway.
>
> Oh, wait... No I don't.
>
> The beauty of the development model I trust is a diverse group of folks
> with a *variety of interests* contributing to various areas of code, in
> turn reviewed by some set of that same varied group, eventually
> committed and merged rolled tested in the wild.
>
> Or however you may see the ideal (or fantasy) of the ecosystem as we
> know, or knew it.
>
> Just the comment in this other related thread, systemd deprecating a
> straightforward encryption setup in version N, what is next?
>
> Okay, I'll go re-wire my tin hat now. Hope someone found this amusing.

Since you beat a lot around the bush, I will try to answer to (what I
believe is) your main point.

Take a look at [1]. That's all the code from the journal.

The format the journal uses to store its logs its binary. There is no
grand conspiracy behind this; it's simply the fact that it wants the
logs indexed so it can search by key on O(log n) time, instead of O(n)
like the regular logs from all the family of syslog. It also compress
them while at it.

The format is binary; but the code to read it (and write it) is not,
and is available for everyone to see. Again, take a look at [1].

You can see the hate systemd generates around. A lot of people are
keeping an eye on it, looking for things to criticize. At the first
moment something fishy got into the journal source code (like your
mail seems to imply is possible), those watchers would howl like there
is no tomorrow. The fact that this hasn't happened is the most simple
proof that there is no grand conspiracy.

You don't believe on the collective eyes of the Linux community? OK,
then *you* take a look trying to find something fishy; everything is
done in the open: again, take a look at [1].

You don't have the necessary abilities to determine if there is
something fishy going on them? Then pay someone to do the analysis for
you; it's probably what Intel, AMD, IBM, Oracle, Valve, and other
companies that have a deep interest in seeing that Linux remain
independent of any single entity have been doing all the time since
systemd (and other core technologies) have appeared.

But I'm going to save you some bucks: there is nothing fishy.

Carry on with the wires on the tin hat.

Regards.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/journal
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 02/15/2014 08:09 PM, walt wrote:
>> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
>>> The social
>>> tactics at work from the systemd team (and verily, other Red Hat
>>> projects like GNOME) are reminiscent of Microsoft through the use of the
>>> "Embrace, Extend, Extinguish" methodology.
>>
>> I certainly share your hostility towards M$ for suppressing competition.
>>
>> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
>> that they want to suppress their competitors (though I don't know who
>> their competitors are).
>>
>> But comparing a completely closed-source shop like M$ to any open source
>> company leaves me feeling uneasy.  I can't find the exact argument to
>> explain my unease, but I'm hoping someone else will jump in with a more
>> rational argument.
>>
> I think I understand where you're coming from. "How can they compare
> when Red Hat releases their source under a liberating license while MS
> locks it down behind closed doors?"
>
> That's missing the point, though.

No, it's not.

> In the FOSS world, that's the "bait",
> so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
> on) a bunch of attractive software or features, get people interested
> (so interested that, say, the majority of distros depend on it *wink
> wink*), and then use that influence to indirectly control where FOSS
> moves. By striking the weakest part of the stack (sysv probably *did*
> need a good replacement, but not one as ambitious as systemd) and
> digging down into the kernel level (kdbus), Red Hat devs will now have a
> very influential role in the FOSS world. This will in turn generate
> interest (and thus profit) in Red Hat.

First of all, you do realize that Greg Kroah-Hartman, the primary
author of kdbus, works for the Linux Foundation, right? Not RedHat.

Second, good for RedHat if they can turn a profit. Meanwhile the code
from the whole stack is free, and anyone willing and able can fork it
and use, enhance, or replace any part of it. And yes, I said replace.

So, again, the comparison makes no sense at all.

> It's marginally clever, but so clearly obvious at the same time. It's
> sad (to me) that the community didn't see it coming.

So you are saying we are idiots? Or just naive? Or both? And *all* of
us who use systemd and think is a great idea?

Damn, if only we had knew. Too bad you didn't come before to open our
eyes to this undeniable truth. Now it's too late, the sky is falling
and the world will end on fire and brim.

> Those who did have
> been written off as conspiracy theorists or FUDders. Time will reveal all.

Indeed it will. Wanna bet a beer?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 6:16 PM, Michael Higgins <linux@evolone.org> wrote:
> On Thu, 20 Feb 2014 15:37:09 -0800
> Michael Higgins <linux@evolone.org> wrote:
>
>> Okay, I'll go re-wire my tin hat now. Hope someone found this amusing.
>
> One other thought I'd has was, well, as long as systemd doesn't, like,
> implement some kind of net protocol, so to make it possible to ship
> logs from systemdjournalcontrol.

Of course it has; you can configure the journal to send the logs of
different machines to a central server, so even if the machine gets
compromised, the logs just prior to the attack are available for
analysis. If you are *really* interested in the topic, take a look at
this neat LWN article about it [1].

[ sniped the rest of the conspiracy theory ]

Regards.

[1] http://lwn.net/Articles/512895/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote:
> On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>> On 02/15/2014 08:09 PM, walt wrote:
>>> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
>>>> The social
>>>> tactics at work from the systemd team (and verily, other Red Hat
>>>> projects like GNOME) are reminiscent of Microsoft through the use of the
>>>> "Embrace, Extend, Extinguish" methodology.
>>>
>>> I certainly share your hostility towards M$ for suppressing competition.
>>>
>>> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
>>> that they want to suppress their competitors (though I don't know who
>>> their competitors are).
>>>
>>> But comparing a completely closed-source shop like M$ to any open source
>>> company leaves me feeling uneasy.  I can't find the exact argument to
>>> explain my unease, but I'm hoping someone else will jump in with a more
>>> rational argument.
>>>
>> I think I understand where you're coming from. "How can they compare
>> when Red Hat releases their source under a liberating license while MS
>> locks it down behind closed doors?"
>>
>> That's missing the point, though.
> 
> No, it's not.
> 
>> In the FOSS world, that's the "bait",
>> so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
>> on) a bunch of attractive software or features, get people interested
>> (so interested that, say, the majority of distros depend on it *wink
>> wink*), and then use that influence to indirectly control where FOSS
>> moves. By striking the weakest part of the stack (sysv probably *did*
>> need a good replacement, but not one as ambitious as systemd) and
>> digging down into the kernel level (kdbus), Red Hat devs will now have a
>> very influential role in the FOSS world. This will in turn generate
>> interest (and thus profit) in Red Hat.
> 
> First of all, you do realize that Greg Kroah-Hartman, the primary
> author of kdbus, works for the Linux Foundation, right? Not RedHat.
> 
> Second, good for RedHat if they can turn a profit. Meanwhile the code
> from the whole stack is free, and anyone willing and able can fork it
> and use, enhance, or replace any part of it. And yes, I said replace.
> 
> So, again, the comparison makes no sense at all.
> 
>> It's marginally clever, but so clearly obvious at the same time. It's
>> sad (to me) that the community didn't see it coming.
> 
> So you are saying we are idiots? Or just naive? Or both? And *all* of
> us who use systemd and think is a great idea?
> 
> Damn, if only we had knew. Too bad you didn't come before to open our
> eyes to this undeniable truth. Now it's too late, the sky is falling
> and the world will end on fire and brim.
> 
>> Those who did have
>> been written off as conspiracy theorists or FUDders. Time will reveal all.
> 
> Indeed it will. Wanna bet a beer?
> 
> Regards.
> 

Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
he worked for Novell, another for-profit Linux company. Moot point.
Businesses tend to do favors for other businesses. What makes you think
Red Hat hasn't given LF some money at some point? Further, isn't Lennart
friends with Greg? Isn't that how he got udev into systemd, since Greg
maintained udev before it was merged into systemd? Tell the full story
if you're going to bring it up.

I will refrain from stooping to the level of petty insults... but yes,
collectively the FOSS community at large has *terrible* social awareness
within its own ecosystem and would not see an agenda coming until it was
too late and they had to fork or rebuild. It has nothing to do with me;
it has everything to do with foresight. And the FOSS world is lacking in
that. Those that have it are outnumbered by those who get distracted by
shiny objects and if they care about the future of FOSS, it's only in a
superficial sense.

FOSS is not just code, it's culture too.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 8:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote:
>> On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>>> On 02/15/2014 08:09 PM, walt wrote:
>>>> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
>>>>> The social
>>>>> tactics at work from the systemd team (and verily, other Red Hat
>>>>> projects like GNOME) are reminiscent of Microsoft through the use of the
>>>>> "Embrace, Extend, Extinguish" methodology.
>>>>
>>>> I certainly share your hostility towards M$ for suppressing competition.
>>>>
>>>> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
>>>> that they want to suppress their competitors (though I don't know who
>>>> their competitors are).
>>>>
>>>> But comparing a completely closed-source shop like M$ to any open source
>>>> company leaves me feeling uneasy.  I can't find the exact argument to
>>>> explain my unease, but I'm hoping someone else will jump in with a more
>>>> rational argument.
>>>>
>>> I think I understand where you're coming from. "How can they compare
>>> when Red Hat releases their source under a liberating license while MS
>>> locks it down behind closed doors?"
>>>
>>> That's missing the point, though.
>>
>> No, it's not.
>>
>>> In the FOSS world, that's the "bait",
>>> so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
>>> on) a bunch of attractive software or features, get people interested
>>> (so interested that, say, the majority of distros depend on it *wink
>>> wink*), and then use that influence to indirectly control where FOSS
>>> moves. By striking the weakest part of the stack (sysv probably *did*
>>> need a good replacement, but not one as ambitious as systemd) and
>>> digging down into the kernel level (kdbus), Red Hat devs will now have a
>>> very influential role in the FOSS world. This will in turn generate
>>> interest (and thus profit) in Red Hat.
>>
>> First of all, you do realize that Greg Kroah-Hartman, the primary
>> author of kdbus, works for the Linux Foundation, right? Not RedHat.
>>
>> Second, good for RedHat if they can turn a profit. Meanwhile the code
>> from the whole stack is free, and anyone willing and able can fork it
>> and use, enhance, or replace any part of it. And yes, I said replace.
>>
>> So, again, the comparison makes no sense at all.
>>
>>> It's marginally clever, but so clearly obvious at the same time. It's
>>> sad (to me) that the community didn't see it coming.
>>
>> So you are saying we are idiots? Or just naive? Or both? And *all* of
>> us who use systemd and think is a great idea?
>>
>> Damn, if only we had knew. Too bad you didn't come before to open our
>> eyes to this undeniable truth. Now it's too late, the sky is falling
>> and the world will end on fire and brim.
>>
>>> Those who did have
>>> been written off as conspiracy theorists or FUDders. Time will reveal all.
>>
>> Indeed it will. Wanna bet a beer?
>>
>> Regards.
>>
>
> Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
> he worked for Novell, another for-profit Linux company. Moot point.
> Businesses tend to do favors for other businesses. What makes you think
> Red Hat hasn't given LF some money at some point? Further, isn't Lennart
> friends with Greg? Isn't that how he got udev into systemd, since Greg
> maintained udev before it was merged into systemd? Tell the full story
> if you're going to bring it up.

So, now it's RedHat, Novell and the Linux Foundation. Anyone else? The
NSA? The CIA? The Cobra Commander?

The Cobra Commander is always involved.

> I will refrain from stooping to the level of petty insults... but yes,
> collectively the FOSS community at large has *terrible* social awareness
> within its own ecosystem and would not see an agenda coming until it was
> too late and they had to fork or rebuild. It has nothing to do with me;
> it has everything to do with foresight. And the FOSS world is lacking in
> that. Those that have it are outnumbered by those who get distracted by
> shiny objects and if they care about the future of FOSS, it's only in a
> superficial sense.

Gee, if I though that about our community, then I would not want to be
part of it.

Good think I don't think like you.

> FOSS is not just code, it's culture too.

Exactly, and it seems you miss the whole point about the FOSS culture too.

I will not answer any more of your mails until you present some actual
evidence about this big bad group of people under the guidance of
shady corporations trying to take advantage of the poor, stupid,
social inept FOSS community.

I do not care about hearsay. I care about facts, and technological
arguments. If you do not have any of those, I'm done with you in this
thread.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/20/2014 08:53 PM, Canek Peláez Valdés wrote:
> On Thu, Feb 20, 2014 at 8:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>> On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote:
>>> On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>>>> On 02/15/2014 08:09 PM, walt wrote:
>>>>> On 02/15/2014 12:30 PM, Daniel Campbell wrote:
>>>>>> The social
>>>>>> tactics at work from the systemd team (and verily, other Red Hat
>>>>>> projects like GNOME) are reminiscent of Microsoft through the use of the
>>>>>> "Embrace, Extend, Extinguish" methodology.
>>>>>
>>>>> I certainly share your hostility towards M$ for suppressing competition.
>>>>>
>>>>> Red Hat, like M$, is a for-profit corporation, so I share your suspicion
>>>>> that they want to suppress their competitors (though I don't know who
>>>>> their competitors are).
>>>>>
>>>>> But comparing a completely closed-source shop like M$ to any open source
>>>>> company leaves me feeling uneasy.  I can't find the exact argument to
>>>>> explain my unease, but I'm hoping someone else will jump in with a more
>>>>> rational argument.
>>>>>
>>>> I think I understand where you're coming from. "How can they compare
>>>> when Red Hat releases their source under a liberating license while MS
>>>> locks it down behind closed doors?"
>>>>
>>>> That's missing the point, though.
>>>
>>> No, it's not.
>>>
>>>> In the FOSS world, that's the "bait",
>>>> so to speak. The wolf in sheep's clothing. Red Hat can release (or hack
>>>> on) a bunch of attractive software or features, get people interested
>>>> (so interested that, say, the majority of distros depend on it *wink
>>>> wink*), and then use that influence to indirectly control where FOSS
>>>> moves. By striking the weakest part of the stack (sysv probably *did*
>>>> need a good replacement, but not one as ambitious as systemd) and
>>>> digging down into the kernel level (kdbus), Red Hat devs will now have a
>>>> very influential role in the FOSS world. This will in turn generate
>>>> interest (and thus profit) in Red Hat.
>>>
>>> First of all, you do realize that Greg Kroah-Hartman, the primary
>>> author of kdbus, works for the Linux Foundation, right? Not RedHat.
>>>
>>> Second, good for RedHat if they can turn a profit. Meanwhile the code
>>> from the whole stack is free, and anyone willing and able can fork it
>>> and use, enhance, or replace any part of it. And yes, I said replace.
>>>
>>> So, again, the comparison makes no sense at all.
>>>
>>>> It's marginally clever, but so clearly obvious at the same time. It's
>>>> sad (to me) that the community didn't see it coming.
>>>
>>> So you are saying we are idiots? Or just naive? Or both? And *all* of
>>> us who use systemd and think is a great idea?
>>>
>>> Damn, if only we had knew. Too bad you didn't come before to open our
>>> eyes to this undeniable truth. Now it's too late, the sky is falling
>>> and the world will end on fire and brim.
>>>
>>>> Those who did have
>>>> been written off as conspiracy theorists or FUDders. Time will reveal all.
>>>
>>> Indeed it will. Wanna bet a beer?
>>>
>>> Regards.
>>>
>>
>> Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
>> he worked for Novell, another for-profit Linux company. Moot point.
>> Businesses tend to do favors for other businesses. What makes you think
>> Red Hat hasn't given LF some money at some point? Further, isn't Lennart
>> friends with Greg? Isn't that how he got udev into systemd, since Greg
>> maintained udev before it was merged into systemd? Tell the full story
>> if you're going to bring it up.
> 
> So, now it's RedHat, Novell and the Linux Foundation. Anyone else? The
> NSA? The CIA? The Cobra Commander?
> 
> The Cobra Commander is always involved.
> 
>> I will refrain from stooping to the level of petty insults... but yes,
>> collectively the FOSS community at large has *terrible* social awareness
>> within its own ecosystem and would not see an agenda coming until it was
>> too late and they had to fork or rebuild. It has nothing to do with me;
>> it has everything to do with foresight. And the FOSS world is lacking in
>> that. Those that have it are outnumbered by those who get distracted by
>> shiny objects and if they care about the future of FOSS, it's only in a
>> superficial sense.
> 
> Gee, if I though that about our community, then I would not want to be
> part of it.
> 
> Good think I don't think like you.
> 
>> FOSS is not just code, it's culture too.
> 
> Exactly, and it seems you miss the whole point about the FOSS culture too.
> 
> I will not answer any more of your mails until you present some actual
> evidence about this big bad group of people under the guidance of
> shady corporations trying to take advantage of the poor, stupid,
> social inept FOSS community.
> 
> I do not care about hearsay. I care about facts, and technological
> arguments. If you do not have any of those, I'm done with you in this
> thread.
> 
> Regards.
> 

Firstly, you don't control whether or not I send an e-mail. The high
horse is completely unnecessary. This particular thread (from walt) had
nothing to do with you directly, so I don't know why you're getting so
upset. You're free to hit the "Delete" button in your e-mail client or
add me to your spam filter.

I said nothing specific about the LF. What I *did* say is that Greg and
Lennart have some sort of friendship that resulted in systemd swallowing
udev. What technical argument supports that and makes systemd important
enough to be the only project worthy of guiding udev's development? What
technical reason does Greg have to implement kdbus? What technical
reason does the systemd community have to push its project onto every
single popular distribution?

Before you retort with "it hasn't", go read the numerous arguments (just
like this one) that have been had on all the distros' mailing lists. In
every last one of them, the systemd proponents pushed and pushed a
decision, insisting that one must be made, and systemd must be the one
that's chosen. It was aggressively evangelized and marketing. To see it
any other way is to be willfully ignorant or simply dishonest.

Here's a logical argument: Red Hat is a for-profit company. Employees
that do not earn them profits are not valuable assets. Ergo, Lennart
Poettering must be profitable to Red Hat in some way. He has created
PulseAudio, maintained *kit, and is now head of systemd and pushed for
kdbus in the kernel. His community has pushed for systemd across the
entire ecosystem. He pushed systemd as a dependency in GNOME, another
Red Hat employee-lead project. Why would Red Hat, as a company, allow
this to happen if they wouldn't profit from it? If Lennart's work is
profitable to Red Hat, then spreading systemd and implementing kdbus
will make Red Hat money. Red Hat's profiting from this growth of
development means that it was a deliberate effort and they intend to
continue taking advantage of the free labor that's built FOSS into what
it is today. This was not accidental and was not in the spirit of FOSS.
It's FOSS only as far as the code (copyleft licensing), which is the
bare minimum.

Other companies have contributed code, yes, but where? The kernel! To
support their devices! The only *legitimate* place for a company to
really contribute code. They make the hardware, so they're the most
qualified to write drivers for it.

So tell me what entitles Red Hat (or any other business) to financially
profit from the work of thousands of volunteers and influence the ecosystem.

I don't think it's some big huge generic evilness at all. It's just
greed, the fuel of every business. Like it or not, companies are based
on and are powered by greed. Even if they license their code under
GPL/MIT/BSD, it's still all about the money, or they wouldn't write code
at all. Consider the source (of the code and the source code itself). If
you disagree with this, I'm not sure why you think Red Hat is in the
software business.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Thu, Feb 20, 2014 at 8:53 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-20 12:43 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafl<tanstaafl@libertytrek.org>
>> wrote:
>>>
>>> On 2014-02-19 2:04 AM, Daniel Campbell<lists@sporkbox.us>  wrote:
>>>>
>>>>
>>>> For such a profile to be legitimate, systemd would have to be chosen as
>>>> the default.
>>>
>>>
>>> Ridiculous. Forget about Canek's rant...
>>>
>>> This is about *choice*. Also, I would argue the *opposite of what Canek
>>> is
>>> saying in this last rant...
>
>
>> Tanstaafl, can we please not use terms like "rants"? I'm just giving
>> my opinion, trying to be respectful and civil to the others
>> participants in this thread. I would appreciate if you do the same to
>> me.
>
>
> Sorry, Canek, no offense was intended, but if you go back and re-read your
> 'extremely overly enthusiastic' post (this plus the content is why I
> referred to it as a 'rant'), while I agree with most everything you said,
> your primary point - that it should be the people who *don't* want systemd
> doing all of the work - was backwards, and that was what I wanted to point
> out.

I'm afraid this is the part that's backwards.

>
> So, please, don't take it as an insult. In fact you have done a very good
> job of patiently spelling out the advantages of systemd, to the point I'm no
> longer afraid of it taking over and devouring the linux world.

If systemd truly is, as you say "taking over and devouring the linux world"
such that the majority of distro maintainers are individually choosing
to use a feature or two from it, then yes, it definitely is the job of people
who want to opt out of it to do the work.

If Gnome wants systemd, and you don't, but you want to continue using
Gnome, it's _your_ job to look for a method or patch or package or script
that makes it work.

If udev wants systemd, and you don't, but you want to continue using
udev, it's _your_ job to look for a method or patch or package or script
that makes it work.

If foo wants systemd, and you don't, but you want to continue using
foo, it's _your_ job to look for a method or patch or package or script
that makes it work.

If everybody else wants to use systemd but you, it's your job to keep
your system working the way you want to.

Nobody's going to go out of their way to specifically and targettedly break
your system, because you don't like their way. However, you can co-opt
some package maintainer's way and say he's obligated to make a
"pure" and "systemd uncorrupted" system for you. Because he's not.

> Bottom line: since Gentoo's default and primary init system is (and
> hopefully will be for a very long time) OpenRC, it is on the systemd folks
> to do the work to get systemd fully supported.
>

systemd IS supported and working. The problem arises when there are
people that want to push for a "system with no systemd whatsoever"
and act like it's the systemd maintainer's job to make that happen.

-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Mark David Dumlao wrote:
> If udev wants systemd, and you don't, but you want to continue using
> udev, it's _your_ job to look for a method or patch or package or
> script that makes it work.

That's already done.  It's called eudev.  :-D

Dale

:-)  :-) 


-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]

On Fri, 21 Feb 2014 11:36:15 +0800 Mark David Dumlao wrote:
[...]
> > So, please, don't take it as an insult. In fact you have done a very good
> > job of patiently spelling out the advantages of systemd, to the point I'm no
> > longer afraid of it taking over and devouring the linux world.
> 
> If systemd truly is, as you say "taking over and devouring the linux world"
> such that the majority of distro maintainers are individually choosing
> to use a feature or two from it, then yes, it definitely is the job of people
> who want to opt out of it to do the work.
> 
> If Gnome wants systemd, and you don't, but you want to continue using
> Gnome, it's _your_ job to look for a method or patch or package or script
> that makes it work.

1. I do _not_ want to use Gnome (and never used it) as DE.
2. Someone called Lennart was a long-time Gnome contributor before
Gnome required systemd without alternative. Coincidence? I don't
believe in them. I trust probabilities and statistics.

> If udev wants systemd, and you don't, but you want to continue using
> udev, it's _your_ job to look for a method or patch or package or script
> that makes it work.

We have eudev fork which is clean from systemd crapware and works
perfectly on production setutps.

> If foo wants systemd, and you don't, but you want to continue using
> foo, it's _your_ job to look for a method or patch or package or script
> that makes it work.
> 
> If everybody else wants to use systemd but you, it's your job to keep
> your system working the way you want to.

Nobody else requires systemd mandatory now as to my knowledge.

> Nobody's going to go out of their way to specifically and targettedly break
> your system, because you don't like their way. However, you can co-opt
> some package maintainer's way and say he's obligated to make a
> "pure" and "systemd uncorrupted" system for you. Because he's not.
> 
> > Bottom line: since Gentoo's default and primary init system is (and
> > hopefully will be for a very long time) OpenRC, it is on the systemd folks
> > to do the work to get systemd fully supported.
> >
> 
> systemd IS supported and working. The problem arises when there are
> people that want to push for a "system with no systemd whatsoever"
> and act like it's the systemd maintainer's job to make that happen.

OpenRC is default in Gentoo now, and it is my best hope it will be.
Thus anyone willing to use something else should do an appropriate
job.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

20.02.2014 19:24, Alan McKinnon пишет:
> On 20/02/2014 13:53, Yuri K. Shatroff wrote:
>> I don't need such 'solutions' to non-existent problems. But if there
>> were a *real* necessity to pretty-print a log's tail in service status,
>> I think it would have been a matter of a proper setup (i.e. the service
>> using syslog, hence a defined log format) and not a heck more complicated.
>>
>>> Definetly not a 5-minutes job.
>>
>> 5 minutes is even too much to type sort of
>> tail -${LINES} ${SERVICE}.log
>> if you know where to look up LINES and SERVICE.
>
>
> You've never actually tried this, right?

You probably misunderstood. I don't *intend* to try this myself with 
existing tools, I'm speaking of the init scripts modification. I say 
that this modification of e.g. OpenRC, if required, would be done quite 
easily with some assumptions.

> Your idea instantly fails as the rc-service author has no idea of what
> you defined ${SERVICE} to be and no way to determine what it is now.

Yes, the rc-service author does not have any idea because he is not 
requested to.
${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
1. putting LINES= in /etc/conf.d/${SERVICE}
2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and 
doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe 
'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or *whatever*)
3. adding this `tail -n ...` or whatever call to the init script .
4. voila.

If you feel I'm again entirely wrong please point out why.

> How are you going to deal with the situation with a big busy daemon that
> immediately starts serving requests when started (i.e. with very little
> delay)?

Either you or I seem to have misunderstood again.
The problem in question IMO was to add the output of last N log entries 
to `*service status` analogous to systemctl status.
When you do tail -n $FILE, don't you *always* get the last N lines of 
the file at the moment of issuing the cmd, regardless whether the file 
is being added a million lines per second. I don't think that journalctl 
can essentially work differently.

> By the time grep, sed, awk and friends have gotten around to making
> their way through a log file of varying size, the entries that apply to
> restart can easy be many hundreds of log lines prior.

Why do you refer to restart?

Canek wrote:

 >> systemctl status apache2.service

 >> (see [2]) will print the status of the Apache web server, and also
 >> the last lines from the logs. You can control how many lines

I don't notice anything about restart here. Just print out the last N lines.

If the question were about [re]start logs, and if in general you are 
getting millions of entries written to the logs, you could use DBMS (not 
necessarily relational). Maybe this *does* require some mess to setup 
(we did it back in times of SunOS), but it could be resolved with 
OpenRC/any SysV/BSD init (at the init-scripts level) if really necessary.
Am I wrong?

> I have done this, and it does not work. I got a result and it's
> relaible, but you don't want to know what it took. It's also highly
> customized and useless to anything other than my highly customized setup.

Well, if you have to set up one system from scratch then probably it's 
easier to use one generalized tool. But if you have an already 
long-working setup which suits your needs, I believe it's relatively 
easy to deploy it on other systems.
I don't like truisms but there is no generic setup suitable for 
everything. Neither is systemd-journald.

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote:
> It's marginally clever, but so clearly obvious at the same time. It's
> sad (to me) that the community didn't see it coming. Those who did have
> been written off as conspiracy theorists or FUDders. Time will reveal all.

Indeed time reveals everything and part of this foiled plot
revealed itself two days ago. It was said earlier in the list by
systemd supporters, that this project is modular, fine split to
binaries and thus critical issues in the pid 1 are not that likely.
And just look at systemd-209 release notes:

http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
[quote] We merged libsystemd-journal.so, libsystemd-id128.so,
libsystemd-login and libsystemd-daemon into a a single libsystemd.so
to reduce code duplication and avoid cyclic dependencies (see below).
[/quote]

So all talks about systemd being modular are nothing more than
nonsense. Guess what will happen on segfault in libsystemd.so?
Segfaults in pid 1 are so nice to bear...

And Canek please talk no more about how "talented" systemd
programmers are or even about how "professional" they are, because
they're no longer. They failed a trivial textbook example: what should
one do when libraries A and B have some common code and cyclic deps?
Push common code to library C. That's the Unix way and secure way.
Creating single bloated library will help in neither fencing nor
debugging, nor code audit.

It looks like to me that ultimate goal of systemd is to consume as
much system and user tools and interfaces as possible. Perhaps, in the
ideal systemd world there will be nothing but linux-systemd kernel and
systemd-stuff userspace. Shell communication will extinct, all major
application and daemons will be converted to systemd "modules". Of
course this goal will be never achieved as-is, but one may consider
it as an asymptote of their actions.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[the]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/19/14 14:37, Gevisz wrote:
> On Tue, 18 Feb 2014 22:53:12 +0400
> the <the.guard@mail.ru> wrote:
> 
> On 02/18/14 17:56, Gevisz wrote:
>>>> On Mon, 17 Feb 2014 23:30:42 -0600 Canek Peláez Valdés
>>>> <caneko@gmail.com> wrote:
>>>>
>>>>> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@gmail.com>
>>>>> wrote: [ snip ]
>>>>>> How can you be sure if something is "large enough" if, as you
>>>>>> say below, you do not care about probabilities?
>>>>>
>>>>> By writing correct code?
>>>>
>>>> No, by arguing that fixing bugs in a 200K line program is as easy
>>>> as fixing a bug in 20 10K line programs. It is just not true, just
>>>> the opposite.
>>>>
>>>>>>>> SysVinit code size is about 10 000 lines of code, OpenRC
>>>>>>>> contains about 13 000 lines, systemd — about 200 000
>>>>>>>> lines.
>>>>>>>
>>>>>>> If you take into account the thousands of shell code that
>>>>>>> SysV and OpenRC need to fill the functionality of systemd,
>>>>>>> they use even more.
>>>>>>>
>>>>>>> Also, again, systemd have a lot of little binaries, many of
>>>>>>> them optional. The LOC of PID 1 is actually closer to SysV
>>>>>>> (although still bigger).
>>>>>>>
>>>>>>>> Even assuming systemd code is as mature as sysvinit or
>>>>>>>> openrc (though I doubt this) you can calculate
>>>>>>>> probabilities of segfaults yourself easily.
>>>>>>>
>>>>>>> I don't care about probabilities;
>>>>>>
>>>>>> If you do not care (= do not now anything) about probabilities 
>>>>>> (and mathematics, in general), you just unable to understand 
>>>>>> that debugging a program with 200K lines of code take
>>>>>>
>>>>>> 200000!/(10000!)^20
>>>>>>
>>>>>> more time than debugging of 20 different programs with 10K
>>>>>> lines of code. You can try to calculate that number yourself
>>>>>> but I quite sure that if the latter can take, say, 20 days, the
>>>>>> former can take millions of years.
>>>>>>
>>>>>> It is all the probability! Or, to be more precise,
>>>>>> combinatorics.
>>>>>
>>>>> My PhD thesis (which I will defend in a few weeks) is in
>>>>> computer science, specifically computational geometry and
>>>>> combinatorics.
>>>>
>>>> It is even more shameful for you to not understand such a simple
>>>> facts from elementary probability theory (which is mostly based on 
>>>> combinatorics).
> TBH I don't understand your estimate. Where did permutations come
> from? are you comparing all the different combinations of lines of
> code?
> 
>> I just wanted to convey that, if an involved program is n times longer,
>> than another one, it does not, in general, true that it will take only
>> n times more time to find a bug. The dependence here would be nonlinear
>> and with much more steep growth than the linear one, just because all
>> the possible ways to go wrong grows proportional to permutations, not
>> necessary of lines but at least of some other units whose number is
>> roughly proportional to the number of lines. 
As I see it:
Suppose we can have b different paths in each unit of code
(for 1 unit having 1 input we would get b possible outputs).
Suppose we have A different states after executing N units, but we
have 1 more unit to execute at the end. Executing the final
unit A times with different initial states we get b outcomes for
each of the A initial states. Now we have A*b possible final states,
so we get b^(n+1) states after executing N+1 units.
If there are s mistakes we can make in each unit we will get 2^s paths
in each unit. Finally 2^(s*N)I may be glitching though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJTBxE1AAoJEK64IL1uI2haoFMH/Ag/JJEh3OZBUf6lR+bp3iV5
HQOh+V+J2vclDcOqc2AQDEYFIR++3yo1iqlw9vW8pI2wSRvcia2j0fs1M/kamvhH
xJC+yaeDQ9dy544PQS/y1vnSxK4nqyTybZ0/yj4liRofkY+4Gyn+hZanPO6R04cn
UDXH/K0uvlhSyIaFRkzmCD8wrEH/slPPGtB3+GwpSckM4MUwtNsjLyng78+AhX9j
A2m5pKrFVHnE09XqGKm+G4La2LeNy33fOTgfL4O/s8q8xCRkIuf/B2mEO/76eUwn
QYjSN77sLtDFfxJSfO46Gch3nA3obcKBVqZkVtqy5Z83m3OjqwKT7xu4yLLHM4Y=
=4zVQ
-----END PGP SIGNATURE-----

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 21/02/2014 09:03, Yuri K. Shatroff wrote:
>> Your idea instantly fails as the rc-service author has no idea of what
>> you defined ${SERVICE} to be and no way to determine what it is now.
> 
> Yes, the rc-service author does not have any idea because he is not
> requested to.
> ${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
> The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
> 1. putting LINES= in /etc/conf.d/${SERVICE}
> 2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and
> doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe
> 'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or
> *whatever*)
> 3. adding this `tail -n ...` or whatever call to the init script .
> 4. voila.
> 
> If you feel I'm again entirely wrong please point out why.


The faults with your comments are many, and I'm not going to detail them
as that's not my job. I'm going to let you figure it out for yourself in
production why your entire approach is wrong, and simply leave you with
this:

You violate DRY.

You expect the sysadmin to know they must make changes in a restart
config file when they tweak the syslogger so that somehow the init
script continues to get it right. Trust me, sysadmins are not going to
remember to do that, because expecting them to is off the wall crazy.

I repeat what I and Canek said earlier:

You've never actually DONE any of this in real life, right?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

21.02.2014 12:48, Alan McKinnon пишет:
> On 21/02/2014 09:03, Yuri K. Shatroff wrote:
>>> Your idea instantly fails as the rc-service author has no idea of what
>>> you defined ${SERVICE} to be and no way to determine what it is now.
>>
>> Yes, the rc-service author does not have any idea because he is not
>> requested to.
>> ${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
>> The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
>> 1. putting LINES= in /etc/conf.d/${SERVICE}
>> 2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and
>> doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe
>> 'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or
>> *whatever*)
>> 3. adding this `tail -n ...` or whatever call to the init script .
>> 4. voila.
>>
>> If you feel I'm again entirely wrong please point out why.
>
>
> The faults with your comments are many, and I'm not going to detail them
> as that's not my job. I'm going to let you figure it out for yourself in
> production why your entire approach is wrong, and simply leave you with
> this:
>
> You violate DRY.

For an example showing the general possibility to do this, I don't 
violate anything. One could easily grep a syslog config , or do the 
opposite (a syslog config generator from service configs), whatever. Of 
course I didn't write a complete logging-aware init scripts system 
because it's also not my job. But if it were, I'm pretty sure it's 
doable under SysV/BSD init in compliance with DRY and ease-of-use for 
admins. I'm sorry I couldn't convince you of that.

> You expect the sysadmin to know they must make changes in a restart
> config file when they tweak the syslogger so that somehow the init
> script continues to get it right. Trust me, sysadmins are not going to
> remember to do that, because expecting them to is off the wall crazy.
>
> I repeat what I and Canek said earlier:
>
> You've never actually DONE any of this in real life, right?

What exactly?
No, I didn't tweak any init system to print the last N log entries for a 
service. No, because I don't need it and never did.
I *did* set up logging to a remote DB on SunOS and FreeBSD. But actually 
you're digressing and just going personal, because the question wasn't 
*how to setup logging* but *the possibility* of such a modification that 
*prints the last N log entries* in the service status cmd.

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 9:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
> Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
> he worked for Novell, another for-profit Linux company.

Good god, is that the best you can do?

What is your aversion to 'profit', anyway? You do realize that 
*everyone* operates under the profit motive, right? EVERYONE. All day. 
Every day, in everything that they do. It may not always be a 
*financial* profit motive, but in many or even most cases it ultimately is.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/21/2014 07:24 AM, Tanstaafl wrote:
> On 2014-02-20 9:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>> Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
>> he worked for Novell, another for-profit Linux company.
> 
> Good god, is that the best you can do?
> 
> What is your aversion to 'profit', anyway? You do realize that
> *everyone* operates under the profit motive, right? EVERYONE. All day.
> Every day, in everything that they do. It may not always be a
> *financial* profit motive, but in many or even most cases it ultimately is.
> 

This discussion has nothing to do with me.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 8:34 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 02/21/2014 07:24 AM, Tanstaafl wrote:
>> On 2014-02-20 9:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>>> Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however,
>>> he worked for Novell, another for-profit Linux company.

>> Good god, is that the best you can do?
>>
>> What is your aversion to 'profit', anyway? You do realize that
>> *everyone* operates under the profit motive, right? EVERYONE. All day.
>> Every day, in everything that they do. It may not always be a
>> *financial* profit motive, but in many or even most cases it ultimately is.

> This discussion has nothing to do with me.

So stop making comments in this thread.

Or are you suggesting that I mis-attributed that post (I just 
dbl-checked and I didn't)?

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 7:08 PM, Daniel Campbell <lists@sporkbox.us> wrote:
> By striking the weakest part of the stack (sysv probably*did*
> need a good replacement, but not one as ambitious as systemd) and
> digging down into the kernel level (kdbus), Red Hat devs will now have a
> very influential role in the FOSS world. This will in turn generate
> interest (and thus profit) in Red Hat.

I sure wish someone who has Linus' ear would ask him to post a blog (or 
even lkml post) dissecting this entire systemd question.

Or, if anyone on here is a member of the lkml and is brave enough, post 
a question there asking for opinions from Linus and any other kernel dev 
who wishes to rant about it...

As it stands now, for me, I don't see a real problem anymore...

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Daniel Campbell]

On 02/21/2014 07:43 AM, Tanstaafl wrote:
> On 2014-02-21 8:34 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> On 02/21/2014 07:24 AM, Tanstaafl wrote:
>>> On 2014-02-20 9:39 PM, Daniel Campbell <lists@sporkbox.us> wrote:
>>>> Indeed, Greg doesn't work for Red Hat. Prior to working for LF,
>>>> however,
>>>> he worked for Novell, another for-profit Linux company.
> 
>>> Good god, is that the best you can do?
>>>
>>> What is your aversion to 'profit', anyway? You do realize that
>>> *everyone* operates under the profit motive, right? EVERYONE. All day.
>>> Every day, in everything that they do. It may not always be a
>>> *financial* profit motive, but in many or even most cases it
>>> ultimately is.
> 
>> This discussion has nothing to do with me.
> 
> So stop making comments in this thread.
> 
> Or are you suggesting that I mis-attributed that post (I just
> dbl-checked and I didn't)?
> 

I certainly wrote what you quoted, but I'm not taking the bait to
devolve this already heated discussion into personal attacks.

If you think all profit is the same, then we are talking on two
different wavelengths.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 10:36 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 8:53 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> Sorry, Canek, no offense was intended, but if you go back and re-read your
>> 'extremely overly enthusiastic' post (this plus the content is why I
>> referred to it as a 'rant'), while I agree with most everything you said,
>> your primary point - that it should be the people who *don't* want systemd
>> doing all of the work - was backwards, and that was what I wanted to point
>> out.

> I'm afraid this is the part that's backwards.

You are wrong.

>> So, please, don't take it as an insult. In fact you have done a very good
>> job of patiently spelling out the advantages of systemd, to the point I'm no
>> longer afraid of it taking over and devouring the linux world.

> If systemd truly is, as you say "taking over and devouring the linux world"

*I* never said that. Others have though, and some still apparently 
believe this to be the case. Admittedly it is those voices that prompted 
me to start this thread. I wanted to get opinions from other list 
members about how systemd is/will/should impact the gentoo community, 
and I'm glad I did. The result is that I now no longer believe most of 
the negatives being spread about systemd, and no longer fear that it is 
'taking over and devouring the linux world'.

> such that the majority of distro maintainers are individually
> choosing to use a feature or two from it, then yes, it definitely is
> the job of  people who want to opt out of it to do the work.

You would be right IF - and I repeat IF - it weren't for the little 
inconvenient fact that OpenRC, not systemd, is the default init system 
in gentoo, now, and thankfully for the foreseeable future. I say 
thankfully not because I fear systemd, but because I would much prefer 
to let systemd mature with others using it to flesh out any bugs or 
other problems/issues (technical *and* political).

As long as OpenRC is the default init system in Gentoo, it is on those 
who want something *other* than OpenRC (ie, systemd) to do the work of 
implementing it.

Why is it so difficult to see that?

Even Canek already acknowledged the correctness of this position.

>> Bottom line: since Gentoo's default and primary init system is (and
>> hopefully will be for a very long time) OpenRC, it is on the systemd folks
>> to do the work to get systemd fully supported.

> systemd IS supported and working. The problem arises when there are
> people that want to push for a "system with no systemd whatsoever"
> and act like it's the systemd maintainer's job to make that happen.

Thankfully there is no problem then, since no one is pushing for 'a 
system with no systemd whatsoever', beyond what exists already.

All I am interested in is keeping the systemd proponents in their place. 
As the 'new kid on the block', when 'invading' (for lack of a better 
term) a new distro (in this case, gentoo), it is *on them* to provide 
the methods and means for people interested in trying/using systemd on 
said distro, but most importantly to do so *without* impacting existing 
users who want to continue using the *existing*, *default* init system 
for their distro.

Are you seriously disagreeing with this position?

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> If you think all profit is the same, then we are talking on two
> different wavelengths.

I didn't say that. I said that *everyone* operates under the profit motive.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Fri, Feb 21, 2014 at 10:02 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2014-02-20 10:36 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
>>
>> On Thu, Feb 20, 2014 at 8:53 PM, Tanstaafl <tanstaafl@libertytrek.org>
>> wrote:
>>> So, please, don't take it as an insult. In fact you have done a very good
>>> job of patiently spelling out the advantages of systemd, to the point I'm
>>> no
>>> longer afraid of it taking over and devouring the linux world.
>
>
>> If systemd truly is, as you say "taking over and devouring the linux
>> world"
>
>
> *I* never said that. Others have though, and some still apparently believe
> this to be the case. Admittedly it is those voices that prompted me to start
> this thread. I wanted to get opinions from other list members about how
> systemd is/will/should impact the gentoo community, and I'm glad I did. The
> result is that I now no longer believe most of the negatives being spread
> about systemd, and no longer fear that it is 'taking over and devouring the
> linux world'.

That's a hypothetical. I'm pointing out that, whatever the situation is, the
reasoning and its justification is backwards. Hence the IF.

It is one thing entirely to say you don't like some software, and another thing
entirely to obligate everyone else in the world to never depend on it.

Your preference of uclibc doesn't obligate every C project in the world to
disavow glibc.

Your preference of firefox doesn't obligate every desktop environment in
the world to disavow chromium.

Your preference of openrc doesn't obligate every package maintainer in
the world to disavow systemd.

Hence the general case above. If you want to use foo without using bar,
but the upstream and package maintainers of foo want to use bar, then
it's _your_ responsibility to make foo work without bar. PERIOD.

You were making it sound like it's the responsibility of the developers of
bar to package versions of foo that don't depend on bar. This is madness.

> Thankfully there is no problem then, since no one is pushing for 'a system
> with no systemd whatsoever', beyond what exists already.

We seem to be reading different mailing lists. The same tinfoilers have
been practically whining for this like it's systemd's fault.
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Feb 20, 2014 at 2:06 PM, Tanstaafl wrote:
>> Thinking about this more, since apparently using a separate
>> profile may just be 'overkill', how about something simpler, like,
>> for example, using eselect...
>>
>> Something like:
>>
>> # eselect init list
>> Available init systems:
>> [1] OpenRC *
>> [2] systemd
>> [3] runit
>>
>> (whatever choices are supported).

> the switching requires reemerging things because you need to set some
> USE flags and quit others. That's the "difficult" (which is not,
> really) part; if you set the USE flags yourself or via a profile, or
> an eselect module, I don't think the difference matters atall.

Ok, so, since it really is so simple, wouldn't it be easier to implement 
this as an eselect module then, as opposed to creating a bunch of 
separate profiles?

(NOTE: to those who might argue it is so trivial that even adding an 
eselect module is overkill, I would respond:

We have eselect modules for changing active profiles and for switching 
active kernels, and as far as I know, all those do is manage a symlink 
(/etc/portage/make.profile for the active profile, and /usr/src/linux).)

Then, if/when a user attempted to switch, eselect could simply spit out 
a warning message about what precisely would be required to complete the 
switch (and this message could be kept updated if/when these 
requirements change), including scary warnings about breakage if they 
fail to complete the steps necessary, then prompt them for confirmation 
(default [n], so an explicit [y] required to execute the change)?

I'd also suggest throwing in a test for current running kernel config, 
to make sure it fully supports booting with systemd, and maybe a new 
emerge command that can also be maintained to make sure that *all* 
necessary packages are rebuilt?

I know, I know, talk is cheap, but again, if systemd proponents want 
systemd on gentoo to ever become a reasonably simple option (or even 
eventually become the new default), I think it is necessary for these 
tools to be built anyway as part of the vetting process, and ultimately 
to provide as many (automated) safeguards as possible to keep new and 
even existing gentoo users from shooting themselves in the foot when 
installing it.

So, the reason I'm explicitly asking is I'd really like for this thread 
to result in a formal feature request to properly shepherd the addition 
of systemd as an optional init system for gentoo, including managing the 
process of switching to it (and back again if desired).

Thanks to all who participated in this thread...

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 9:28 AM, Mark David Dumlao <madumlao@gmail.com> wrote:
> It is one thing entirely to say you don't like some software, and
> another thing entirely to obligate everyone else in the world to
> never depend on it.

All myself and others have been insisting on is that systemd proponents 
be prevented from unilaterally creating some kind of dependenc[y][ies] 
whereby, through that backdoor, they create a situation where the 
*current* *default* init system must be switched.

> Your preference of uclibc doesn't obligate every C project in the
> world to disavow glibc.
>
> Your preference of firefox doesn't obligate every desktop
> environment in the world to disavow chromium.

And your preference for systemd doesn't obligate your distro of choice 
to change to it as the *default* init system.

> Your preference of openrc doesn't obligate every package maintainer
> in the world to disavow systemd.

No one is asking for that.

Again, we are just insisting that systemd proponents be prevented from 
forcing gentoo into a situation where we are *forced* to switch to 
systemd for the *default* init system.

> Hence the general case above. If you want to use foo without using
> bar, but the upstream and package maintainers of foo want to use
> bar, then it's _your_ responsibility to make foo work without bar.
> PERIOD.

I agree... so, if *you* want to use systemd, it is *your* reponsibility 
to make systemd work without impacting existing gentoo users *or* the 
fact that gentoo has selected OpenRC as it's default init system.

> You were making it sound like it's the responsibility of the
> developers of bar to package versions of foo that don't depend on
> bar. This is madness.

Nope, and you are missing the point.

This isn't about individual packages. It is about one of the choices 
that *Distro's* must make - in this case, regarding something very 
significant (the choice of what to use as the default init system).

We, again, are simply insisting that it is the responsibility of the 
developers of systemd to *not* create situations where they *force* 
other distro's into *impossible* *situations* where they are *forced* to 
switch their init systems or have basic system packages stop working.

The best way for gentoo, as a distro, to protect its users and it's 
ecosystem, is to provide a sane, managed approach for systemd proponents 
to get systemd added to gentoo as a formally supported *optional* init 
system.

Then, and only then, can it be judged on its *merits*, and then and 
*only* then should it (imnsho) ever be considered as a potential 
candidate for being made a new *default*.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Gevisz]

On Fri, 21 Feb 2014 09:02:31 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 2014-02-20 10:36 PM, Mark David Dumlao <madumlao@gmail.com> wrote:
> > On Thu, Feb 20, 2014 at 8:53 PM, Tanstaafl
> > <tanstaafl@libertytrek.org> wrote:
> >> Sorry, Canek, no offense was intended, but if you go back and
> >> re-read your 'extremely overly enthusiastic' post (this plus the
> >> content is why I referred to it as a 'rant'), while I agree with
> >> most everything you said, your primary point - that it should be
> >> the people who *don't* want systemd doing all of the work - was
> >> backwards, and that was what I wanted to point out.
> 
> > I'm afraid this is the part that's backwards.
> 
> You are wrong.
> 
> >> So, please, don't take it as an insult. In fact you have done a
> >> very good job of patiently spelling out the advantages of systemd,
> >> to the point I'm no longer afraid of it taking over and devouring
> >> the linux world.
> 
> > If systemd truly is, as you say "taking over and devouring the
> > linux world"
> 
> *I* never said that. Others have though, and some still apparently 
> believe this to be the case. Admittedly it is those voices that
> prompted me to start this thread.

Do you hear voices? :-)

> I wanted to get opinions from other
> list members about how systemd is/will/should impact the gentoo
> community, and I'm glad I did. The result is that I now no longer
> believe most of the negatives being spread about systemd, and no
> longer fear that it is 'taking over and devouring the linux world'.
> 
> > such that the majority of distro maintainers are individually
> > choosing to use a feature or two from it, then yes, it definitely is
> > the job of  people who want to opt out of it to do the work.
> 
> You would be right IF - and I repeat IF - it weren't for the little 
> inconvenient fact that OpenRC, not systemd, is the default init
> system in gentoo, now, and thankfully for the foreseeable future. I
> say thankfully not because I fear systemd, but because I would much
> prefer to let systemd mature with others using it to flesh out any
> bugs or other problems/issues (technical *and* political).
> 
> As long as OpenRC is the default init system in Gentoo, it is on
> those who want something *other* than OpenRC (ie, systemd) to do the
> work of implementing it.
> 
> Why is it so difficult to see that?
> 
> Even Canek already acknowledged the correctness of this position.
> 
> >> Bottom line: since Gentoo's default and primary init system is (and
> >> hopefully will be for a very long time) OpenRC, it is on the
> >> systemd folks to do the work to get systemd fully supported.
> 
> > systemd IS supported and working. The problem arises when there are
> > people that want to push for a "system with no systemd whatsoever"
> > and act like it's the systemd maintainer's job to make that happen.
> 
> Thankfully there is no problem then, since no one is pushing for 'a 
> system with no systemd whatsoever', beyond what exists already.
> 
> All I am interested in is keeping the systemd proponents in their
> place. As the 'new kid on the block', when 'invading' (for lack of a
> better term) a new distro (in this case, gentoo), it is *on them* to
> provide the methods and means for people interested in trying/using
> systemd on said distro, but most importantly to do so *without*
> impacting existing users who want to continue using the *existing*,
> *default* init system for their distro.
> 
> Are you seriously disagreeing with this position?
> 

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Gevisz]

On Fri, 21 Feb 2014 09:03:47 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 2014-02-21 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> > If you think all profit is the same, then we are talking on two
> > different wavelengths.
> 
> I didn't say that. I said that *everyone* operates under the profit
> motive.

And that is simply not true.

OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 10:28 AM, Gevisz <gevisz@gmail.com> wrote:
> On Fri, 21 Feb 2014 09:03:47 -0500
> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>
>> On 2014-02-21 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>> If you think all profit is the same, then we are talking on two
>>> different wavelengths.
>>
>> I didn't say that. I said that *everyone* operates under the profit
>> motive.
>
> And that is simply not true.

Yes, it is, but you may be confused about the meaning of 'profit'.

Even someone who volunteers in the local soup kitchen feeding the 
homeless is doing so under the profit motive. The things is, the 
'profit' involved (may) only involve(s) a 'warm fuzzy good feeling'.

If you read my previous words, I said it wasn't always (though I think 
it is usually) some kind of 'financial' profit.

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[»Q«]

On Fri, 21 Feb 2014 09:02:31 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> As long as OpenRC is the default init system in Gentoo, it is on
> those who want something *other* than OpenRC (ie, systemd) to do the
> work of implementing it.

It's the job of whoever wants any init system to work to make it work,
isn't it?  There's no magic that makes the default work without
it being someone's job to make it work.

No matter what the default is, for any init system to work, there has
to be a group of people committed to making it work.  There are such
groups for OpenRC and systemd within Gentoo.  And since Gentoo is about
choice, each group bears the burden of doing whatever is reasonable to
make sure it doesn't interfere with users' ability to run whichever
system they want.  Reaching a consensus about "whatever is reasonable"
isn't always a pretty process, but they have to do it anyway.

I'm an OpenRC user, and I intend to remain one, but I wouldn't mind if
Gentoo had no default init system and the user would have to choose
one at install time via a profile choice, eselect, or just a bunch of
USE flags, as long as the choices are well documented.

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tanstaafl:
> On 2014-02-21 10:28 AM, Gevisz <gevisz@gmail.com> wrote:
>> On Fri, 21 Feb 2014 09:03:47 -0500 Tanstaafl
>> <tanstaafl@libertytrek.org> wrote:
>> 
>>> On 2014-02-21 8:54 AM, Daniel Campbell <lists@sporkbox.us>
>>> wrote:
>>>> If you think all profit is the same, then we are talking on
>>>> two different wavelengths.
>>> 
>>> I didn't say that. I said that *everyone* operates under the
>>> profit motive.
>> 
>> And that is simply not true.
> 
> Yes, it is, but you may be confused about the meaning of 'profit'.
> 
> Even someone who volunteers in the local soup kitchen feeding the 
> homeless is doing so under the profit motive. The things is, the 
> 'profit' involved (may) only involve(s) a 'warm fuzzy good
> feeling'.
> 
> If you read my previous words, I said it wasn't always (though I
> think it is usually) some kind of 'financial' profit.
> 

You didn't say it, but it feels like you are talking about "personal
profit". If not, then your definition of "profit" is so broad, that it
is almost meaningless.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTB32KAAoJEFpvPKfnPDWzvssIALcVgrXn/XGTx5ZmXJjuUpIq
eN6m6pBQ8b8oO5ujZpx9/l2rMt5zNzwaLpHhF5UEZiZXEEqt9+NSOP62vEuGHn2y
Xk5JUDNngIuQaz4geKJXs9YcyA2ZV1MFhZYaxDBOq4DZ4+j75e0FiHuh3jGHfr1+
qUkZWxyWAxoIGb3CUWTedgpr6HqzMJWycL8BDutItfp7dpCobGoY2DSRKX3iSH73
1jtfOx+Ec2QScAmy+fi7sVN9yp5sSSlM4YVmzS5nSw2zemsYVmfqhrTNdPAcy2QE
k1xlalMzoIY2EGi68ThjRniXrAQoH2R7kfQsavFSVfratbjjuvdDHxa4sNnbjAE=
=V8cT
-----END PGP SIGNATURE-----

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 11:23 AM, hasufell <hasufell@gentoo.org> wrote:
>> Even someone who volunteers in the local soup kitchen feeding the
>> homeless is doing so under the profit motive. The things is, the
>> 'profit' involved (may) only involve(s) a 'warm fuzzy good
>> feeling'.
>>
>> If you read my previous words, I said it wasn't always (though I
>> think it is usually) some kind of 'financial' profit.

> You didn't say it, but it feels like you are talking about "personal
> profit". If not, then your definition of "profit" is so broad, that it
> is almost meaningless.

Not at all. The fact is, there are many different ways someone can 'profit'.

Another fact is, there has been a concerted effort by some people to 
poison the meaning, twisting the meaning of financial profit into being 
something bad, as opposed to what it really is - a very *good* thing (it 
is a good thing, without it you would DIE).

http://dictionary.reference.com/browse/profit?sourceid=mozilla

Take your pick... they are all valid with respect to my comments, 
although the one that subtley attempts to create a negative meaning 'to 
take advantage: to profit from the WEAKNESS of others' bugs me no end...

People can engage in good (ethical, honest, etc) or bad (unethical, 
dishonest, etc) behavior in their pursuit of profit, but it is the 
*behavior* (ethical/honest or unethical/dishonest) that is good or bad, 
not the result (profit).

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tanstaafl:
> On 2014-02-21 11:23 AM, hasufell <hasufell@gentoo.org> wrote:
>>> Even someone who volunteers in the local soup kitchen feeding
>>> the homeless is doing so under the profit motive. The things
>>> is, the 'profit' involved (may) only involve(s) a 'warm fuzzy
>>> good feeling'.
>>> 
>>> If you read my previous words, I said it wasn't always (though
>>> I think it is usually) some kind of 'financial' profit.
> 
>> You didn't say it, but it feels like you are talking about
>> "personal profit". If not, then your definition of "profit" is so
>> broad, that it is almost meaningless.
> 
> Not at all. The fact is, there are many different ways someone can 
> 'profit'.
> 
> Another fact is, there has been a concerted effort by some people
> to poison the meaning, twisting the meaning of financial profit
> into being something bad, as opposed to what it really is - a very
> *good* thing (it is a good thing, without it you would DIE).
> 
> http://dictionary.reference.com/browse/profit?sourceid=mozilla
> 
> Take your pick... they are all valid with respect to my comments, 
> although the one that subtley attempts to create a negative meaning
> 'to take advantage: to profit from the WEAKNESS of others' bugs me
> no end...
> 
> People can engage in good (ethical, honest, etc) or bad
> (unethical, dishonest, etc) behavior in their pursuit of profit,
> but it is the *behavior* (ethical/honest or unethical/dishonest)
> that is good or bad, not the result (profit).
> 

Then you ignore self-destructive behaviour which is a common thing in
this world. It can even be intentional, causing no emotional,
financial, social or intellectual profit. Maybe you have never met
such a person or have never been in such an environment.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTB4oUAAoJEFpvPKfnPDWzKwkH/jZMgmx20pvKBJBSHBzVgzYn
GCEo4y6OVLKR4MkOMFPbgDh0OiPyLAGwj9A2QJmstTO2UN9LVwdkZLZIT1V4/kK9
3UGoxz5Q/vgLawnJxKesBmq0Qq1acwaEXojT/tngBpLStYvOcNU3Mq4kDlzAcOJ3
tDVoUpxV7fvsAjJZ7hd4LXVWN3vYC/8AYnAfO6K9Cb+VlGIkGDZ6bYDs0k8Wflxn
jdEYdsh0k1Bbr5aDZGXRO9pZl7scLRr8SJha0DJwIhc5ZuazyXrX9R8SNw+QSjN8
NiGUIRWMjvwKuziFqRWCGyOJVpbyoaJkg1fxcOHlWvOyHHcOM9TSHHhhGL7Bg3E=
=U4Qh
-----END PGP SIGNATURE-----

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 02/20/2014 08:06 PM, Tanstaafl wrote:
>
>
> Thinking about this more, since apparently using a separate profile
> may just be 'overkill', how about something simpler, like, for
> example, using eselect...
>
> Something like:
>
>  # eselect init list
> Available init systems:
>   [1]   OpenRC *
>   [2]   systemd
>   [3]   runit
>
> (whatever choices are supported).
>
>
>
+1 from here
Personally i'm most likely to stay with openRC, because the switch is
non-trivial and have no faith in the xinetd-style socket arbitrator.

but would eselect be able to script the following:
.. new kernel coptions
.. new grub2 command line
.. install dbus (use=-systemd) _then_ systemd
.. would be nice to use an import for localed and hostnamed and timedated
.. importing openrc services and runlevels to targets
.. pamd logind entires
.. syslogd changes to accomodate systemd
.. setting systemd to log to syslog to make transitions smoother (as
logs are lost on reboot by default)

and then the reverse for 'undo' ?

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 12:17 PM, hasufell <hasufell@gentoo.org> wrote:
> Then you ignore self-destructive behaviour which is a common thing in
> this world. It can even be intentional, causing no emotional,
> financial, social or intellectual profit. Maybe you have never met
> such a person or have never been in such an environment.

You are confusing 'intent' with 'result'.

Even self-destructive behavior is in the vast majority of cases engaged 
in with the *intention* of profit. Best example I can think of would be 
a drug addict/alcoholic. When they use/drink, they 'profit' in that the 
feel better (albeit temporarily), regardless of the ultimate result.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 12:33 PM, thegeezer <thegeezer@thegeezer.net> wrote:
> On 02/20/2014 08:06 PM, Tanstaafl wrote:
>> Thinking about this more, since apparently using a separate profile
>> may just be 'overkill', how about something simpler, like, for
>> example, using eselect...
>>
>> Something like:
>>
>>   # eselect init list
>> Available init systems:
>>    [1]   OpenRC *
>>    [2]   systemd
>>    [3]   runit
>>
>> (whatever choices are supported).

> +1 from here
> Personally i'm most likely to stay with openRC, because the switch is
> non-trivial and have no faith in the xinetd-style socket arbitrator.
>
> but would eselect be able to script the following:
> .. new kernel coptions
> .. new grub2 command line
> .. install dbus (use=-systemd)_then_  systemd
> .. would be nice to use an import for localed and hostnamed and timedated
> .. importing openrc services and runlevels to targets
> .. pamd logind entires
> .. syslogd changes to accomodate systemd
> .. setting systemd to log to syslog to make transitions smoother (as
> logs are lost on reboot by default)
>
> and then the reverse for 'undo' ?

Well, there are two aspects to consider: new install (where most of the 
above are not an issue), and switching back and forth.

Only a dev can answer your questions with respect to the latter. 
Everything Canek and others were saying led me to believe it was more 
trivial/less work than your questions suggest, so I'll just have to 
leave the answers to those who know so much more than I...

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tanstaafl:
> On 2014-02-21 12:17 PM, hasufell <hasufell@gentoo.org> wrote:
>> Then you ignore self-destructive behaviour which is a common
>> thing in this world. It can even be intentional, causing no
>> emotional, financial, social or intellectual profit. Maybe you
>> have never met such a person or have never been in such an
>> environment.
> 
> You are confusing 'intent' with 'result'.

No. You are confusing yourself with the rest of the world.

> 
> Even self-destructive behavior is in the vast majority of cases
> engaged in with the *intention* of profit. Best example I can think
> of would be a drug addict/alcoholic. When they use/drink, they
> 'profit' in that the feel better (albeit temporarily), regardless
> of the ultimate result.
> 

I wasn't really talking about drug addicts.

If you are interested in real self-destructive behaviour, talk to
someone who has worked in an asylum which is only one interesting
environment that can make you think very different about "people".

There are even people who are not driven by anything, not even
self-destruction. Pure apathy.

Another interesting thing... talk to a trial lawyer who has been in
that business for 10+ years. I really doubt that many of those will
support your "profit intention" concept. Most of the time it's about
short-cut reactions that are merely following instincts or emotional
impulses. Strong emotions can make someone lose control and do all
sorts of weird things without any hope or intention of
improving/gaining anything for living it out.
It's chemistry, it changes your consciousness. "Profit" is a bit more
complex and requires a minimum amount of reflection, even if it is
subconscious, short sighted and follows false assumptions.

So these are just 3 points why your generalization does not work, like
most of those "all people..." phrases. Unless you hack on the
definition until it suits your interpretation, like redefining "profit
intention" to "intention".

This reminds me of "the user" in computer science papers. Well, which one.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTB6qKAAoJEFpvPKfnPDWzD5MH/3qVBSactWRWng+x1bT29eP/
Vsd3pSdP5GJ5JkH8Vj2LAhRJy9feRselI/TnZuXOOT+gTzAT+ip1fgqmIHTkaLEx
Z1a4L5WXEQxTq9aSoaBFzxstont0zb6LWHfW+c8H+V6UTXPUv6ZdGqP+PlLMLpYO
az0KiB09PMa/a3LOzPjhACQ6s1aRo5d4mUqOG91rxh3bOljt6WlMJ61ZEATQGwZt
iZJff4sO0qG9p6YeoZED0ep6QvH4UGkfl3yboiVf08uf9mbGSTnOffe5GSJqeBKo
9uGK/tJJ4vkYqcEG60pZaqBuIguobzh84rwWg8DGs++Nv9dWbXi7Focpdse/OaU=
=8l+x
-----END PGP SIGNATURE-----

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 2:35 PM, hasufell <hasufell@gentoo.org> wrote:
> Tanstaafl:
>> On 2014-02-21 12:17 PM, hasufell <hasufell@gentoo.org> wrote:
>>> Then you ignore self-destructive behaviour which is a common
>>> thing in this world. It can even be intentional, causing no
>>> emotional, financial, social or intellectual profit. Maybe you
>>> have never met such a person or have never been in such an
>>> environment.

>> You are confusing 'intent' with 'result'.

> No. You are confusing yourself with the rest of the world.

Not really, but whatever...

>> Even self-destructive behavior is in the vast majority of cases
>> engaged in with the *intention* of profit. Best example I can think
>> of would be a drug addict/alcoholic. When they use/drink, they
>> 'profit' in that the feel better (albeit temporarily), regardless
>> of the ultimate result.

> I wasn't really talking about drug addicts.

You said 'self-destructive', so I just used the best 'self-destructive' 
reference I could think of...

> If you are interested in real self-destructive behaviour, talk to
> someone who has worked in an asylum which is only one interesting
> environment that can make you think very different about "people".

Ok, well, I wasn't talking about the truly *insane*, and it is 
disingenuous to use them as any kind of example in comparison to 'the 
rest of us'...

> There are even people who are not driven by anything, not even
> self-destruction. Pure apathy.

I guarantee they are driven by more than that... often something as 
simple as 'comfort' (they would only get up in arms if you take away 
their TV and potato chips)...

> Another interesting thing... talk to a trial lawyer who has been in
> that business for 10+ years. I really doubt that many of those will
> support your "profit intention" concept. Most of the time it's about
> short-cut reactions that are merely following instincts or emotional
> impulses. Strong emotions can make someone lose control and do all
> sorts of weird things without any hope or intention of
> improving/gaining anything for living it out.

Again, you ignore the different meanings of 'profit' and 'intent'. 
Following instincts or emotional impulses is *still* operating on the 
same principle. The profit (benefit) they get may be as simple as 'less 
pain', but it is still a benefit (profit).

> It's chemistry, it changes your consciousness. "Profit" is a bit more
> complex and requires a minimum amount of reflection, even if it is
> subconscious, short sighted and follows false assumptions.

Not at all. A bull 'profits' by moving when the cattle prod is jammed up 
his ass.

> So these are just 3 points why your generalization does not work,

Actually, they all serve to *support* my generalizations... if you are 
in fact honest enough to admit it.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote:
> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@antarean.org> wrote:
>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
>
> [ snip ]
>
>>> Of course the larger a project is the *potential* number of bugs
>>> increases, but so what? With enough developers, users and testers, all
>>> bugs are *potentially* squashed.
>>
>> Agreed, but I know of enough large projects with large development teams
>> and even more users that don't get the most basic bugs fixed.
>> Quantity is not equivalent to Quality.
>
> I also agree with that. My point is that the systemd project has
> enough numbers of *talented* developers to do it.
>
> You can disagree, of course.

Talented developer, maybe.
But not talented designers.

>>> And systemd has a *much* wider community than any other init system.
>>> So it can handle a larger code base.
>>
>> Incorrect. How many people use systemd as opposed to SysV Init?
>
> Users? Like five thousand godzillions more.

I tend to disagree.
Systemd is ONLY on Linux.
SysV init can be found on alot of other platforms used in the world. Think
Solaris, AIX, HPuX and Linux machines that have not had their init-systems
changed.

> Developers? It would not surprise me that systemd has several times
> more developers that SysV ever had.

Maybe, but the developers back then still followed the unix-way: Have a
tool do one job and do it well.
From what I see from systemd, it tries to do too much and the single jobs
suffer from feature-bloat.

> What's more, I think those developers are talented enough, to say the
> least.

I miss talented designers.

>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>>>> > about 13 000 lines, systemd — about 200 000 lines.
>>>>>
>>>>> If you take into account the thousands of shell code that SysV and
>>>>> OpenRC need to fill the functionality of systemd, they use even more.
>>
>> The shell-code is proven to work though and provided with most of the
>> software. Where it isn't provided, it can be easily created.
>> I have seen (and used) complex start-up scripts for large software
>> implementations which complex dependencies.
>> Fortunately, later versions of those software packages have fixed that
>> mess to a large extend, but I wonder how well systemd unit-files can
>> work
>> in such an environment.
>
> You can read [1]. I think it provides a fair and impartial account of
> how to use systemd to start a complex service (NFS, by its author).

I would not class NFS as a complex service.
I am talking about a dozen different services that need to be started in a
specific order where the next one is not allowed to start before the
previous one actually responds to TCP/IP connections.

How would I configure that in systemd unit-files?

If I were to have sockets created in advance (does it work with TCP/IP
sockets?) I would get timeouts on the responses which would lead to some
services not starting correctly and ending up in limbo...

>> Having sockets created prior to service start will not work as
>> components
>> will fail due to time-outs, leaving even a bigger mess.
>
> I could be wrong, but I believe the use of cgroups takes care of all
> that. If the service fails, systemd PID 1 can reliable detect it, and
> force the socket to close, and even reopen it for new connections if
> so configured by the administrator.

Force the socket to close? That's nice, goodbye connection to one of the
databases. Hello auto-shutdown of services because something is clearly
wrong.
With auto-restart, that will create an interesting sequence of events
designed to really break the installation.

>>>> If that code will fail, this wouldn't be critical at system level.
>>>> Thus scope of fatal error is limited.
>>>
>>> Also in systemd, since most of its code is not critical (again;
>>> logind, datetimed, localed, etc., failing, has no impact whatsoever on
>>> the rest of the system).
>>
>> I understand the usecase for "logind", but what is the point of a daemon
>> to supply the time (datetimed)? Is this a full replacement for "ntpd"?
>> And what does "localed" do? That's configured once in the environment
>> and
>> should be handled using environment variables.
>
> I'm sorry, but *everything* you are asking for is in the link I gave
> you that you qualified it of "not necessary for this discussion" (I
> also pointed someone else to [2]). If you are really interested in the
> answers, go on and read it there.
>
> It's certainly better than hearing it from me.

Maybe, but based on the name, and I am assuming the names have some sort
of relevance, localed makes no sense.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Thu, February 20, 2014 06:24, Canek Peláez Valdés wrote:
> On Wed, Feb 19, 2014 at 2:50 AM, J. Roeleveld <joost@antarean.org> wrote:
>> On Tue, February 18, 2014 15:37, Canek Peláez Valdés wrote:
>>> On Tue, Feb 18, 2014 at 3:54 AM, J. Roeleveld <joost@antarean.org>
>>> wrote:

<snipped>

>> Same question applies, can I disable these code-paths during
>> compile-time?
>
> No you can't; if you wanted the journal to work exactly as rsyslog (or
> syslog-ng), then there is no reason to use the journal. Its raison
> d'être is the new features it brings.
>
> If you don't want those features, don't use the journal.

Which means, don't use systemd, as it's all or nothing there.

>> I do not see the need to have to spend time to change working code to be
>> able to handle different formats.
>
> Well, I prefer it when someone does the work for me.

So do I, but I doubt the systemd developers are willing to change all my
scripts and monitoring tools to work with systemd.

>> Additionally, the use of "tail -f" and "grep" allows me to check the
>> logs
>> real-time for debugging purposes.
>
> journalctl -f
>
> Checks the logs in real time. Again, [1].
>
>> Having to use a seperate tool that converts some proprietary binary
>> format
>> to human readable/scriptable single-line logs makes no sense.
>
> Its not proprietary; the source code is available, you can write your
> own parser if you want. The binary format is to be able to do O(log n)
> searches, that's it. It's a performance optimization.

The specification for Office Open XML is also available. I do not see
Libreoffice or Openoffice properly supporting that yet either, even though
there is great demand and a large development team (with sufficient
financing) available.

>> It all sounds too much like the MS Windows Event-viewer to me.
>
> Never used it.

It's a binary, indexed logging system that is part of the OS. Sounds
similar to journald.

>> Too many events with no usefull logging information (And I am referring
>> to
>> OS-level messages as to why default services are not starting)
>
> systemctl status apache2.service
>
> (see [2]) will print the status of the Apache web server, and also the
> last lines from the logs. You can control how many lines. You can
> check also with the journal, as I showed up.

/etc/init.d/apache2 status will also tell me if it is running.
And which logs?
On a host with only 1 domain pointing to it, I have 6 logfiles for apache.
And that is the default configuration.

And what I was referring to was the useless info found in the event-log
for services that are not written to actually use it.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Fri, February 21, 2014 18:33, thegeezer wrote:
> On 02/20/2014 08:06 PM, Tanstaafl wrote:

<snipped>

> .. setting systemd to log to syslog to make transitions smoother (as
> logs are lost on reboot by default)

Eeerh, logs are lost on reboot?
I only had (it died last weekend) one (yes, ONE) machine that was so
configured and that was a netbook with only 16GB SSD.

On all my machines I want to SEE the logs especially if it reboots
unexpectedly.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Thu, February 20, 2014 16:16, Alan McKinnon wrote:
> On 20/02/2014 11:16, Yuri K. Shatroff wrote:
>>
>>
>> 20.02.2014 09:24, Canek Peláez Valdés пишет:
>>> [ snip ]
>>>> but I do not see the point, beyond as a nice gimmick.
>>>
>>> Well, I *do* see a point. Many points, actually. You want the logs for
>>> SSH, from February 12 to February 15? Done:
>>>
>>> journalctl  --since=2014-02-12 --until=2014-02-15 -u sshd.service
>>>
>>> No grep. No cat. No hunting logrotated logs (the journal will rotate
>>> automatically its logs, and will search on all logs available). You
>>> can have second-precision intervals.
>>>
>>> Also, the binary format that the journal uses is indexed (hence the
>>> binary part); therefore, the search is O(log n), no O(n). With a log
>>> with a million entries, that's about 20 steps.
>>>
>>> Perhaps it's just a gimmick to you. For me is a really usefull
>>
>> Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n))
>> if really needed is easily achieved with databases.
>> Not using cat and grep is not something one'd boast; rather, again, a
>> waste of resources to recreate already existing tools.
>> BTW, I wonder if anyone does really have logs with millions of lines in
>> one single file, not split into files by date, service etc, so that the
>> whole O(n) issue is moot.
>
> I have logs like that. It's not an uncommon scenario.

I've seen logdirectories containing a a few hundred MB of logs on a test
environment with a single user doing just one thing.
Fortunately, there was a single file which indicated which of the 200+
files contained the actual error message I was looking for.

>> I believe it would be a 5-minutes job to add the capability of printing
>> last N log entries for a service to `rc-service status`. Using cat, grep
>> and the like.
>
>
> No, that will not work easily for all definitions of easily.
>
> rc-something has zero control over where the logs go and no standard
> method to provide "hints" to the logger. Gentoo ships syslog* configs
> that basically stick everything in messages, where grepping them out is
> a PITA. I usually rewrite that config more to my taste and needs and
> rc-service cannot know what I did. So the idea fails at step 1 as the
> code does not know where the logs are.

Would journald?

>> Not reinventing wheels. Not spending super-talented
>> super-highly paid developers' time on doing tasks one had done about 30
>> years ago. I believe, not having this option is due to its simple
>> uselessness.
>
> 30 years ago we had isolated stand-alone machines without nothing like
> the logging needs we have today. Whilst I agree with you that systemd's
> logging tools may not be the solution, I can assure you (as someone who
> has to deal with this shit) that syslogging in the modern world is a mess.
>
> Try this: Decide you cannot afford Splunk, so do it yourself. Now get
> your Apache access logs into the same searchable database your other
> stuff is in, and do it in such a way that you can SELECT what you want
> out in obvious ways.
>
> Repeat for every other app you have that logs stuff. Remember to find
> the really important logs which are usually sitting in /opt/ and
> produced by Log4Perl or something equally abominable.

Replace "perl" for a different 4-letter world depicting a language
commonly used for enterprise applications supported on multiple platforms
and you get what I have to deal with.

One of those has the more commonly needed logs in 4 or 5 locations. This
can easily end up being a lot more, depending on how it is being used. A
script to find all those would need admin-level permissions into the
application itself to query information needed to find the logfiles.

Another application I worked with in the past had 20+ locations. A few of
which contained 100+ logfiles after a few days of use. At least 5 of those
didn't even have time-stamps.

For those, a clever utility would be useful, but if I could write that,
I'd use those AI-routines to take over the world ;)

--
Joost

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 9:22 PM, Daniel Campbell <lists@sporkbox.us> wrote:

(When I say "I'm done", I mean it; I'm making an exception to explain
a mistake you made).

> Firstly, you don't control whether or not I send an e-mail.

No, I don't; I never said that. This is a public non-moderated mailing
list; anyone can write whatever it wants.

What I said is *I* am done with *you*. You are only spreading FUD
without giving any hard evidence nor any technical argument. Therefore
*I* am not going to waste anymore of *my* time answering your mails in
this thread, until you either provide hard evidence (not hearsay),
and/or technical arguments.

You are of course free to write whatever you want to the list. I'm
just not going to engage with you anymore, until you provide those two
basic things.

And since you haven't in this new mail... good day, sir.

[ sniped the part without any hard evidence nor technical arguments. ]

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Thu, Feb 20, 2014 at 9:36 PM, Mark David Dumlao <madumlao@gmail.com> wrote:

[ snip ]

> If systemd truly is, as you say "taking over and devouring the linux world"

Mark, although I agree with much of your mail (but not all), I don't
think is fair how you are treating Tanstaafl; he never said that.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Sebastian Beßler]

On 21.02.2014 08:42, Andrew Savchenko wrote:

> So all talks about systemd being modular are nothing more than
> nonsense. Guess what will happen on segfault in libsystemd.so?
> Segfaults in pid 1 are so nice to bear...

And now with 209 there is a new systemd-networkd deamon that is started
by default even if not configured or used.

http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTI

Why has a init system a deamon to configure networks?

What comes next? Systemd-Windowsd, a systemd replacement for all other
desktop environments? Systemd-Browserd? Systemd-Officed?

Greetings

Sebastian

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Michael Higgins]

On Thu, 20 Feb 2014 19:40:46 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

[...]

> But I'm going to save you some bucks: there is nothing fishy.
> 
> Carry on with the wires on the tin hat.
> 
> Regards.

Perfect. So that nails that bugaboo as well.

All is good, then, absolutely nothing to see here.

Thanks again for all you've done to convince us there's nothing
nefarious going on.

Cheers,

- mykhyggz

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Fri, 21 Feb 2014 09:32:07 -0500, Tanstaafl wrote:

> Ok, so, since it really is so simple, wouldn't it be easier to
> implement this as an eselect module then, as opposed to creating a
> bunch of separate profiles?

profiles handle USE flags, eselect does not. Of course, you can use
eselect to change profiles :)

It's not as complex as creating a lot of different systemd profiles
because of inheritance.

> I'd also suggest throwing in a test for current running kernel config, 
> to make sure it fully supports booting with systemd, and maybe a new 
> emerge command that can also be maintained to make sure that *all* 
> necessary packages are rebuilt?

That's already taken care of, the systemd ebuild checks your kernel
config as part of the pre-emerge checks, nothing happens until you have a
suitable kernel.


-- 
Neil Bothwick

If at first you don't succeed, redefine success.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Fri, Feb 21, 2014 at 1:42 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
> On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote:
>> It's marginally clever, but so clearly obvious at the same time. It's
>> sad (to me) that the community didn't see it coming. Those who did have
>> been written off as conspiracy theorists or FUDders. Time will reveal all.
>
> Indeed time reveals everything and part of this foiled plot
> revealed itself two days ago. It was said earlier in the list by
> systemd supporters, that this project is modular, fine split to
> binaries and thus critical issues in the pid 1 are not that likely.
> And just look at systemd-209 release notes:
>
> http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
> [quote] We merged libsystemd-journal.so, libsystemd-id128.so,
> libsystemd-login and libsystemd-daemon into a a single libsystemd.so
> to reduce code duplication and avoid cyclic dependencies (see below).
> [/quote]
>
> So all talks about systemd being modular are nothing more than
> nonsense. Guess what will happen on segfault in libsystemd.so?
> Segfaults in pid 1 are so nice to bear...

You have no idea what are you talking about, do you?

The systemd binary (you know, PID 1) *DOESN'T LINK AGAINST libsystemd.so!*

It's for consumers of systemd's APIs.

> And Canek please talk no more about how "talented" systemd
> programmers are or even about how "professional" they are, because
> they're no longer. They failed a trivial textbook example: what should
> one do when libraries A and B have some common code and cyclic deps?
> Push common code to library C. That's the Unix way and secure way.
> Creating single bloated library will help in neither fencing nor
> debugging, nor code audit.

This actually I'm even willing to discuss. They give the rationale in
the notes you linked: "he reason for this is cyclic dependencies, as
these libraries tend to use each other's symbols."

It's true, they could have splitted even more the libraries, but they
instead coalesced them. If the libraries used each other symbols, then
they basically are functioning as a single module, and then it can be
argued that coalescing them is a good move.

I'm not saying I agree; I think I also would have preferred for them
to split the cycles into another library. But I give the benefit of
the doubt to the maintainers, and certainly would still think they are
talented enough.

(And again, it's a "normal" library, for third-party consumers, not PID 1).

> It looks like to me that ultimate goal of systemd is to consume as
> much system and user tools and interfaces as possible.

Yeah, that's the idea. They have been pretty clear and honest about
it. They want systemd to be the standard basic plumbing of Linux.

> Perhaps, in the
> ideal systemd world there will be nothing but linux-systemd kernel and
> systemd-stuff userspace.

I would call it  "systemd-aware" userspace, but yeah, again, that's the idea.

> Shell communication will extinct, all major
> application and daemons will be converted to systemd "modules".

Why would you disallow shell communication? It's pretty useful. But it
will be complemented with dbus IPC and systemd controlled processes.
It works pretty much like this with GNOME right now.

If you don't want this, just keep using OpenRC. Nobody is forcing
systemd on you.

> Of
> course this goal will be never achieved as-is, but one may consider
> it as an asymptote of their actions.

They want systemd to be the basic plumbing of Linux, yes.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Gevisz]

On Fri, 21 Feb 2014 10:56:31 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 2014-02-21 10:28 AM, Gevisz <gevisz@gmail.com> wrote:
> > On Fri, 21 Feb 2014 09:03:47 -0500
> > Tanstaafl <tanstaafl@libertytrek.org> wrote:
> >
> >> On 2014-02-21 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> >>> If you think all profit is the same, then we are talking on two
> >>> different wavelengths.
> >>
> >> I didn't say that. I said that *everyone* operates under the profit
> >> motive.
> >
> > And that is simply not true.
> 
> Yes, it is, but you may be confused about the meaning of 'profit'.
> 
> Even someone who volunteers in the local soup kitchen feeding the 
> homeless is doing so under the profit motive. The things is, the 
> 'profit' involved (may) only involve(s) a 'warm fuzzy good feeling'.
> 
> If you read my previous words

Yes, I did. But now, I stop to do so just as have done with Canek
before.

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Gevisz]

On Fri, 21 Feb 2014 19:35:39 +0000
hasufell <hasufell@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Tanstaafl:
> > On 2014-02-21 12:17 PM, hasufell <hasufell@gentoo.org> wrote:
> >> Then you ignore self-destructive behaviour which is a common
> >> thing in this world. It can even be intentional, causing no
> >> emotional, financial, social or intellectual profit. Maybe you
> >> have never met such a person or have never been in such an
> >> environment.
> > 
> > You are confusing 'intent' with 'result'.
> 
> No. You are confusing yourself with the rest of the world.

 :-)
 
> > Even self-destructive behavior is in the vast majority of cases
> > engaged in with the *intention* of profit. Best example I can think
> > of would be a drug addict/alcoholic. When they use/drink, they
> > 'profit' in that the feel better (albeit temporarily), regardless
> > of the ultimate result.
> > 
> 
> I wasn't really talking about drug addicts.
> 
> If you are interested in real self-destructive behaviour, talk to
> someone who has worked in an asylum which is only one interesting
> environment that can make you think very different about "people".
> 
> There are even people who are not driven by anything, not even
> self-destruction. Pure apathy.
> 
> Another interesting thing... talk to a trial lawyer who has been in
> that business for 10+ years. I really doubt that many of those will
> support your "profit intention" concept. Most of the time it's about
> short-cut reactions that are merely following instincts or emotional
> impulses. Strong emotions can make someone lose control and do all
> sorts of weird things without any hope or intention of
> improving/gaining anything for living it out.
> It's chemistry, it changes your consciousness. "Profit" is a bit more
> complex and requires a minimum amount of reflection, even if it is
> subconscious, short sighted and follows false assumptions.
> 
> So these are just 3 points why your generalization does not work, like
> most of those "all people..." phrases. Unless you hack on the
> definition until it suits your interpretation, like redefining "profit
> intention" to "intention".

Thank you for the wonderful answer!
 
> This reminds me of "the user" in computer science papers. Well, which
> one. -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBCgAGBQJTB6qKAAoJEFpvPKfnPDWzD5MH/3qVBSactWRWng+x1bT29eP/
> Vsd3pSdP5GJ5JkH8Vj2LAhRJy9feRselI/TnZuXOOT+gTzAT+ip1fgqmIHTkaLEx
> Z1a4L5WXEQxTq9aSoaBFzxstont0zb6LWHfW+c8H+V6UTXPUv6ZdGqP+PlLMLpYO
> az0KiB09PMa/a3LOzPjhACQ6s1aRo5d4mUqOG91rxh3bOljt6WlMJ61ZEATQGwZt
> iZJff4sO0qG9p6YeoZED0ep6QvH4UGkfl3yboiVf08uf9mbGSTnOffe5GSJqeBKo
> 9uGK/tJJ4vkYqcEG60pZaqBuIguobzh84rwWg8DGs++Nv9dWbXi7Focpdse/OaU=
> =8l+x
> -----END PGP SIGNATURE-----
> 

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Fri, Feb 21, 2014 at 2:14 PM, J. Roeleveld <joost@antarean.org> wrote:
> On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote:
>> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@antarean.org> wrote:
>>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
>>
>> [ snip ]
>>
>>>> Of course the larger a project is the *potential* number of bugs
>>>> increases, but so what? With enough developers, users and testers, all
>>>> bugs are *potentially* squashed.
>>>
>>> Agreed, but I know of enough large projects with large development teams
>>> and even more users that don't get the most basic bugs fixed.
>>> Quantity is not equivalent to Quality.
>>
>> I also agree with that. My point is that the systemd project has
>> enough numbers of *talented* developers to do it.
>>
>> You can disagree, of course.
>
> Talented developer, maybe.
> But not talented designers.

That's subjective. For me (and many others), the design of systemd is sound.

>>>> And systemd has a *much* wider community than any other init system.
>>>> So it can handle a larger code base.
>>>
>>> Incorrect. How many people use systemd as opposed to SysV Init?
>>
>> Users? Like five thousand godzillions more.
>
> I tend to disagree.

I meant that SysV has like five thousand godzillions more that
systemd. Sorry for the confussion.

> Systemd is ONLY on Linux.
> SysV init can be found on alot of other platforms used in the world. Think
> Solaris, AIX, HPuX and Linux machines that have not had their init-systems
> changed.
>
>> Developers? It would not surprise me that systemd has several times
>> more developers that SysV ever had.
>
> Maybe, but the developers back then still followed the unix-way: Have a
> tool do one job and do it well.

Again, for many of us that doesn't matter, and we don't take it like
an article of faith.

> From what I see from systemd, it tries to do too much and the single jobs
> suffer from feature-bloat.

Many of us believe they solve real problems, and they make our life easier.

>> What's more, I think those developers are talented enough, to say the
>> least.
>
> I miss talented designers.

Wonder why?

>>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>>>>> > about 13 000 lines, systemd   about 200 000 lines.
>>>>>>
>>>>>> If you take into account the thousands of shell code that SysV and
>>>>>> OpenRC need to fill the functionality of systemd, they use even more.
>>>
>>> The shell-code is proven to work though and provided with most of the
>>> software. Where it isn't provided, it can be easily created.
>>> I have seen (and used) complex start-up scripts for large software
>>> implementations which complex dependencies.
>>> Fortunately, later versions of those software packages have fixed that
>>> mess to a large extend, but I wonder how well systemd unit-files can
>>> work
>>> in such an environment.
>>
>> You can read [1]. I think it provides a fair and impartial account of
>> how to use systemd to start a complex service (NFS, by its author).
>
> I would not class NFS as a complex service.
> I am talking about a dozen different services that need to be started in a
> specific order where the next one is not allowed to start before the
> previous one actually responds to TCP/IP connections.

If you had read the link, you would have learned that NFS has 14 unit
files, form a lot of daemons that have to run in concurrent form (and
some of them only when others are not, etc.) It *IS* a complex
service.

> How would I configure that in systemd unit-files?

Read the link

> If I were to have sockets created in advance (does it work with TCP/IP
> sockets?) I would get timeouts on the responses which would lead to some
> services not starting correctly and ending up in limbo...

You don't know how the socket activation works, do you? At boot time,
if a service ask for a socket on port 1234 (and yes, they work on
TCP/IP sockets), systemd opens the socket for the service, and the
service *does not start yet*.

When the *first* connection gets into the socket, systemd starts the
service, and when it finishes starting, systemd passes the opened
socket to it as an fd. Done, now the service has control of the
socket, and it will until the services terminates; not when the
connection closes (although you can configure it that way), when the
*service* terminates.

If several connections arrive to the socket *before* the service
finishes starting up, the kernel automatically queues them, and when
systemd handles the socket to the service, the service does it things
for all of them.

There is *no single* connection lost. Well, if a godzillion
connections arrive before the service finishes starting up, the kernel
queue is finite and some would be lost, but it would have to be a lot
of connections arriving in a window of some microseconds.

>>> Having sockets created prior to service start will not work as
>>> components
>>> will fail due to time-outs, leaving even a bigger mess.
>>
>> I could be wrong, but I believe the use of cgroups takes care of all
>> that. If the service fails, systemd PID 1 can reliable detect it, and
>> force the socket to close, and even reopen it for new connections if
>> so configured by the administrator.
>
> Force the socket to close? That's nice, goodbye connection to one of the
> databases. Hello auto-shutdown of services because something is clearly
> wrong.

You are not understanding me; read above. I meant that if the service
*crashes* (and therefore the connections are gone anyway), using
cgroups systemd can reliable detect it and close the associated
sockets (if not closed already), and (if so configured), open the
socket again and wait for connections while the service is restarted.

systemd is *NOT* xinitd.

> With auto-restart, that will create an interesting sequence of events
> designed to really break the installation.

It does not; thanks mostly due to the kernel, it works pretty great.

>>>>> If that code will fail, this wouldn't be critical at system level.
>>>>> Thus scope of fatal error is limited.
>>>>
>>>> Also in systemd, since most of its code is not critical (again;
>>>> logind, datetimed, localed, etc., failing, has no impact whatsoever on
>>>> the rest of the system).
>>>
>>> I understand the usecase for "logind", but what is the point of a daemon
>>> to supply the time (datetimed)? Is this a full replacement for "ntpd"?
>>> And what does "localed" do? That's configured once in the environment
>>> and
>>> should be handled using environment variables.
>>
>> I'm sorry, but *everything* you are asking for is in the link I gave
>> you that you qualified it of "not necessary for this discussion" (I
>> also pointed someone else to [2]). If you are really interested in the
>> answers, go on and read it there.
>>
>> It's certainly better than hearing it from me.
>
> Maybe, but based on the name, and I am assuming the names have some sort
> of relevance, localed makes no sense.

Roeleveld, if you had bothered to read the several links that I have
provided, you could answer all your question and see that you are
wrong about many things about systemd.

That you haven't done it, and that many times that I answer any of
your points, you ignore that one and go on another tangent trying to
discredit systemd, I believe you are not trying to have an honest
technical conversation.

Therefore, I will stop engaging with you at this point.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Fri, Feb 21, 2014 at 3:32 PM, Sebastian Beßler
<sebastian@darkmetatron.de> wrote:
> On 21.02.2014 08:42, Andrew Savchenko wrote:
>
>> So all talks about systemd being modular are nothing more than
>> nonsense. Guess what will happen on segfault in libsystemd.so?
>> Segfaults in pid 1 are so nice to bear...
>
> And now with 209 there is a new systemd-networkd deamon that is started
> by default even if not configured or used.
>
> http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTI

$ ./configure --help | grep networkd
  --disable-networkd      disable networkd

It can be disabled.

> Why has a init system a deamon to configure networks?

So you don't need the same script (or service unit file) that
configures an static IP or bridge, in millions of servers that do not
want to use NetworkManager or anything similar.

Again, is optional, you can disable it.

> What comes next? Systemd-Windowsd, a systemd replacement for all other
> desktop environments? Systemd-Browserd? Systemd-Officed?

Yeah, because configuring an static IP is similar to LibreOffice.

Get real.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Fri, Feb 21, 2014 at 3:37 PM, Michael Higgins <linux@evolone.org> wrote:
> On Thu, 20 Feb 2014 19:40:46 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> [...]
>
>> But I'm going to save you some bucks: there is nothing fishy.
>>
>> Carry on with the wires on the tin hat.
>>
>> Regards.
>
> Perfect. So that nails that bugaboo as well.
>
> All is good, then, absolutely nothing to see here.
>
> Thanks again for all you've done to convince us there's nothing
> nefarious going on.

You are welcome.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: OT: 'profit motive' - WAS Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>>> Even self-destructive behavior is in the vast majority of
>>> cases engaged in with the *intention* of profit. Best example I
>>> can think of would be a drug addict/alcoholic. When they
>>> use/drink, they 'profit' in that the feel better (albeit
>>> temporarily), regardless of the ultimate result.
> 
>> I wasn't really talking about drug addicts.
> 
> You said 'self-destructive', so I just used the best
> 'self-destructive' reference I could think of...

It was not the best.

> 
>> If you are interested in real self-destructive behaviour, talk
>> to someone who has worked in an asylum which is only one
>> interesting environment that can make you think very different
>> about "people".
> 
> Ok, well, I wasn't talking about the truly *insane*, and it is 
> disingenuous to use them as any kind of example in comparison to
> 'the rest of us'...
> 

That is just one example and those are not few people. Ruling them out
in your generalization is invalid and just proves that you are trolling.

"The rest of us" is as well defined as your "profit intention" stuff. Meh.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTB/ZWAAoJEFpvPKfnPDWzO8UIAJHAVyQCrpMp/bW0yKbAnHSK
yvW+15teMgbQZQdru34OYjXHpiLFgjnKF+OwGgOE8+vA908Kawc5Fme2aazYGtC1
gnqFlnnFkMiE37hNvGmef7Jpzl/q1UuZPJHDeh6m0kAJ0QjoxbANxNayQThd1QNX
UrlJEpzOr6LwDrjkTnnwcwzNLymr9EB8NAehqd4B5/jsf0ZFoUo7Zn9DOhlv8olp
PqdnjkVuIgrtVxhd6OBeQ3OVPsE7qyI5ZTfJUDYYef38WJ6PDj2Nc7jEblJKPsxS
NWnZKfS/1w7oIUqnzwS36mKf+PhWrGqefJcIfE3E68DeW+2kxpZlvSCnFMM/sX4=
=eRGW
-----END PGP SIGNATURE-----

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Sat, Feb 22, 2014 at 6:40 AM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, Feb 21, 2014 at 2:14 PM, J. Roeleveld <joost@antarean.org> wrote:
>> On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote:
>>> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@antarean.org> wrote:
>>>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
>>>
>>> [ snip ]
>>>
>>>>> Of course the larger a project is the *potential* number of bugs
>>>>> increases, but so what? With enough developers, users and testers, all
>>>>> bugs are *potentially* squashed.
>>>>
>>>> Agreed, but I know of enough large projects with large development teams
>>>> and even more users that don't get the most basic bugs fixed.
>>>> Quantity is not equivalent to Quality.
>>>
>>> I also agree with that. My point is that the systemd project has
>>> enough numbers of *talented* developers to do it.
>>>
>>> You can disagree, of course.
>>
>> Talented developer, maybe.
>> But not talented designers.
>
> That's subjective. For me (and many others), the design of systemd is sound.
>
>>>>> And systemd has a *much* wider community than any other init system.
>>>>> So it can handle a larger code base.
>>>>
>>>> Incorrect. How many people use systemd as opposed to SysV Init?
>>>
>>> Users? Like five thousand godzillions more.
>>
>> I tend to disagree.
>
> I meant that SysV has like five thousand godzillions more that
> systemd. Sorry for the confussion.
>
>> Systemd is ONLY on Linux.
>> SysV init can be found on alot of other platforms used in the world. Think
>> Solaris, AIX, HPuX and Linux machines that have not had their init-systems
>> changed.
>>
>>> Developers? It would not surprise me that systemd has several times
>>> more developers that SysV ever had.
>>
>> Maybe, but the developers back then still followed the unix-way: Have a
>> tool do one job and do it well.
>
> Again, for many of us that doesn't matter, and we don't take it like
> an article of faith.
>
>> From what I see from systemd, it tries to do too much and the single jobs
>> suffer from feature-bloat.
>
> Many of us believe they solve real problems, and they make our life easier.
>
>>> What's more, I think those developers are talented enough, to say the
>>> least.
>>
>> I miss talented designers.
>
> Wonder why?
>
>>>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>>>>>> > about 13 000 lines, systemd   about 200 000 lines.
>>>>>>>
>>>>>>> If you take into account the thousands of shell code that SysV and
>>>>>>> OpenRC need to fill the functionality of systemd, they use even more.
>>>>
>>>> The shell-code is proven to work though and provided with most of the
>>>> software. Where it isn't provided, it can be easily created.
>>>> I have seen (and used) complex start-up scripts for large software
>>>> implementations which complex dependencies.
>>>> Fortunately, later versions of those software packages have fixed that
>>>> mess to a large extend, but I wonder how well systemd unit-files can
>>>> work
>>>> in such an environment.
>>>
>>> You can read [1]. I think it provides a fair and impartial account of
>>> how to use systemd to start a complex service (NFS, by its author).
>>
>> I would not class NFS as a complex service.
>> I am talking about a dozen different services that need to be started in a
>> specific order where the next one is not allowed to start before the
>> previous one actually responds to TCP/IP connections.
>
> If you had read the link, you would have learned that NFS has 14 unit
> files, form a lot of daemons that have to run in concurrent form (and
> some of them only when others are not, etc.) It *IS* a complex
> service.
>
>> How would I configure that in systemd unit-files?
>
> Read the link

Canek, you're too polite.

This deserves a /usr/src/linux/Documentation/ManagementStyle, chapter 5
reply. At my risk entirely, here is one:

You ignorant nitwit.

Read the fine link. Read the fine docs. Read the fine manual. Read the
fine publicly
posted rationales. Read the fine publicly held distro and package manager
discussions. And know what a fine socket is before you start spouting
your diarrhea crap about spawning sockets in advance.

And if you don't, here's the thing, maybe you're not really familiar
with the "Unix
way" that you're so proud about. Because you don't get to skip all that and make
ridiculous sweeping generalizations and assertions that the docs DO answer.

The so-called Unix way that many of you peeps are waxing priest-like about
is in reality just one aspect, one part of the Unix way, meant to
apply to a particular
class of applications. It doesn't apply to everything.

Especially, text filter design does not apply to applications that are
meant for solving genuinely complex problems - the kernel itself is a glaring
violation of the one small thing doing one thing well rule. And why? One,
because it uses that complexity to solve things that would be harder to do
in the minikernel approach, and two, even as the complex beast it has become
it's still simpler (read: Unixier) than the alternative solution of
interacting servers.

Even as the complex beast it has become systemd is still simpler than the
alternative of having abominations of unreliable shell scripts checking to see
which version of grep and sed is used to split the command line, or whether
the system uses tempfile or mktemp, or depending on perl.

ergo libreoffice. desktop environments. firefox. databases. Heck much of
what's being said about systemd applies to postfix - there's no general case
reason for me to grab some random postfix component and use it for everyday
work, therefore postfix is just some closed-source monolithic virus, right?
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 22.02.2014 11:40, Mark David Dumlao wrote:
> [ ... ]
> Even as the complex beast it has become systemd is still simpler than the
> alternative of having abominations of unreliable shell scripts checking to see
> which version of grep and sed is used to split the command line, or whether
> the system uses tempfile or mktemp, or depending on perl.

Well, simpler yeah, supporting only one kernel of specific versions is 
always simpler than trying to support everything from SunOS to NetBSD. 
This way, if the kernel supported only e.g. Intel IvyBridge+ with one 
chipset family, one graphics (VESA) and so on, it would have been 
incredibly simpler.
Or probably is it systemd that checks "whether the system uses tempfile 
or mktemp"? Or having a new own (NIH) unit config format parser is 
simpler than taking one of thousands of existing ones?
It is simpler for you end user. (Though dubious for users who wield 
shell scripts and perl.) But when it comes to reliability it's entirely 
wrong. I can fix a faulty shell script without having to wait for a new 
release. Or I can even write mine own. Can you fix systemd?

> ergo libreoffice.

A follower of the MS-maintained strategy "one black box that does 
everything". I always wonder what does e.g. Excel/Calc/spreadsheed need 
font decorations for? Or 1+2 is different from *1*+/2/? ;)

> desktop environments.

A good DE design is just a collection of separate tools doing different 
things, united by some graphical design.

 > firefox.

An example of how an app once followed a non-Unix way is now failing to 
get back to the Unix way. And its reliability is somewhere near zero. 
Though, it's almost impossible now to make a simple browser which would 
also be cross-platform and popular. There's a holy bible of standards 
and quirks to support, and yet more in the development phase, for the 
end user to be happy. It's completely different from an init system, 
even all the init systems of all Unixes altogether.

 > databases.

What's wrong with them? Mostly, characteristic examples of the Unix way.

 > Heck much of
> what's being said about systemd applies to postfix - there's no general case
> reason for me to grab some random postfix component and use it for everyday
> work, therefore postfix is just some closed-source monolithic virus, right?

So now that there's a working postfix which is an example of a non-Unix 
way design, it's justified to use this approach everywhere else?


-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 02/21/2014 08:33 PM, J. Roeleveld wrote:
> On Fri, February 21, 2014 18:33, thegeezer wrote:
>> On 02/20/2014 08:06 PM, Tanstaafl wrote:
> <snipped>
>
>> .. setting systemd to log to syslog to make transitions smoother (as
>> logs are lost on reboot by default)
> Eeerh, logs are lost on reboot?
until you configure journald to have persistent logs
> I only had (it died last weekend) one (yes, ONE) machine that was so
> configured and that was a netbook with only 16GB SSD.
>
> On all my machines I want to SEE the logs especially if it reboots
> unexpectedly.
which is why i suggest using syslogd to smooth the transition.  the last
thing anyone wants to do with a new system is learn how to find out
where the error logs are or how to access them from busybox
>

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 02/22/2014 01:21 PM, thegeezer wrote:
> On 02/21/2014 08:33 PM, J. Roeleveld wrote:
>> On Fri, February 21, 2014 18:33, thegeezer wrote:
>>> On 02/20/2014 08:06 PM, Tanstaafl wrote:
>> <snipped>
>>
>>> .. setting systemd to log to syslog to make transitions smoother (as
>>> logs are lost on reboot by default)
>> Eeerh, logs are lost on reboot?
> until you configure journald to have persistent logs
>> I only had (it died last weekend) one (yes, ONE) machine that was so
>> configured and that was a netbook with only 16GB SSD.
>>
>> On all my machines I want to SEE the logs especially if it reboots
>> unexpectedly.
> which is why i suggest using syslogd to smooth the transition.  the last
> thing anyone wants to do with a new system is learn how to find out
> where the error logs are or how to access them from busybox
for those that might need it heads up to make sure you have an initramfs
with journalctl builtin

https://lists.debian.org/debian-devel/2014/02/msg00863.html
>

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]

On Fri, 21 Feb 2014 16:40:46 -0600 Canek Peláez Valdés wrote:
> >>>> Of course the larger a project is the *potential* number of bugs
> >>>> increases, but so what? With enough developers, users and testers, all
> >>>> bugs are *potentially* squashed.
> >>>
> >>> Agreed, but I know of enough large projects with large development teams
> >>> and even more users that don't get the most basic bugs fixed.
> >>> Quantity is not equivalent to Quality.
> >>
> >> I also agree with that. My point is that the systemd project has
> >> enough numbers of *talented* developers to do it.
> >>
> >> You can disagree, of course.
> >
> > Talented developer, maybe.
> > But not talented designers.
> 
> That's subjective. For me (and many others), the design of systemd is sound.

Thanks to your explanation of socket activation it is subjective no
longer. Systemd design flaws may be discussed in sheer technical
terms, see below.
 
> > If I were to have sockets created in advance (does it work with TCP/IP
> > sockets?) I would get timeouts on the responses which would lead to some
> > services not starting correctly and ending up in limbo...
> 
> You don't know how the socket activation works, do you? At boot time,
> if a service ask for a socket on port 1234 (and yes, they work on
> TCP/IP sockets), systemd opens the socket for the service, and the
> service *does not start yet*.
> 
> When the *first* connection gets into the socket, systemd starts the
> service, and when it finishes starting, systemd passes the opened
> socket to it as an fd. Done, now the service has control of the
> socket, and it will until the services terminates; not when the
> connection closes (although you can configure it that way), when the
> *service* terminates.
> 
> If several connections arrive to the socket *before* the service
> finishes starting up, the kernel automatically queues them, and when
> systemd handles the socket to the service, the service does it things
> for all of them.
> 
> There is *no single* connection lost. Well, if a godzillion
> connections arrive before the service finishes starting up, the kernel
> queue is finite and some would be lost, but it would have to be a lot
> of connections arriving in a window of some microseconds.

And here we have a design issue. I already pointed this issue in this
discussion:
http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg144144.html
Though it was completely ignored by you. I understand: it is easier
to discuss design in terms of taste than in technical merits.

Systemd assumes that time required to start service is small (at
microseconds scale). While this is true for widely used simple
setups, this is not true in general case. Service may take seconds or
even minutes to start up (good example are services depending on
enterprise SAN or large databases). And because systemd never assumes
it can take long time to start we have the following issues possible
in general case:

1. Client connections are lost due to timeout when service takes
long time to start. Systemd fakes service to be available while it
isn't still. Thus systemd is not an option for production grade
servers.

2. Even if connection timeout is not reached, requests may pale up and
be lost. Loss trigger depends on memory available, thus systemd is
not an option for both embedded setups and production server setups.

As one can see, while systemd socket activation design will work for
many case, it will fail for corner ones and by no means can't be used
in production (where this corner cases have a high chance to rise).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-21 4:58 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Fri, 21 Feb 2014 09:32:07 -0500, Tanstaafl wrote:
>> Ok, so, since it really is so simple, wouldn't it be easier to
>> implement this as an eselect module then, as opposed to creating a
>> bunch of separate profiles?

> profiles handle USE flags, eselect does not. Of course, you can use
> eselect to change profiles :)
>
> It's not as complex as creating a lot of different systemd profiles
> because of inheritance.

Thanks Neil, but... what are you suggesting then? That it would have to 
be done as profiles, but it wouldn't be really complicated? Or maybe 
that it would be a combination of profile selection and... something 
else (new eselect init module)?

Remember, I want all of this to coalesce into an enhancement/feature 
request for gentoo to be able to provide a sound, sane way to manage the 
idea of switching init systems.

>> I'd also suggest throwing in a test for current running kernel config,
>> to make sure it fully supports booting with systemd, and maybe a new
>> emerge command that can also be maintained to make sure that *all*
>> necessary packages are rebuilt?

> That's already taken care of, the systemd ebuild checks your kernel
> config as part of the pre-emerge checks, nothing happens until you have a
> suitable kernel.

Ok, excellent...

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Stroller]

On Sat, 22 February 2014, at 10:38 am, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:

> On 22.02.2014 11:40, Mark David Dumlao wrote:
>> [ ... ]
>> Even as the complex beast it has become systemd is still simpler than the
>> alternative of having abominations of unreliable shell scripts checking to see
>> which version of grep and sed is used to split the command line, or whether
>> the system uses tempfile or mktemp, or depending on perl.
> 
> Well, simpler yeah, supporting only one kernel of specific versions is always simpler than trying to support everything from SunOS to NetBSD. This way, if the kernel supported only e.g. Intel IvyBridge+ with one chipset family, one graphics (VESA) and so on, it would have been incredibly simpler.

   I’m doing a (free) operating system (just a hobby, won’t be big and
   professional like gnu) for 386(486) AT clones. … PS. Yes – it’s
   free of any minix code, and it has a multi-threaded fs.  It is NOT
   protable (uses 386 task switching etc), and it probably never will
   support anything other than AT-harddisks, as that’s all I have :-(.

Linux did indeed once support only one CPU family and one or two hard-drives, and the reason that it now supports more is that people dug into the code, submitted patches and got it fixed. 

Had all the original Linux developers spent their time on the comp.os.minix list, complaining "oh, those splitters, they're trying to fragment the Minix community" and "this Linus guy should be putting his effort into improving the Minix kernel", where would we be today?

It's almost hilarious the volume of traffic expended here on this subject, especially that by the naysayers. When I first learned of systemd I did not feel favourably towards it, but those ranting against it have only given Canek a platform to convince me.

And whilst I'm still of two minds on which init system I'd ideally prefer, I am not under any delusions that I can influence the developers of the Gentoo distro or those of the Linux kernel (who AIUI are adding kdbus to support systemd), either by ranting about it here or otherwise.

The amount of energy spent on this, you could have established a fork and written code by now - if y'all really want to prove your point, that's the way to do it.

Stroller.

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 22/02/2014 18:37, Tanstaafl wrote:
> On 2014-02-21 4:58 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
>> On Fri, 21 Feb 2014 09:32:07 -0500, Tanstaafl wrote:
>>> Ok, so, since it really is so simple, wouldn't it be easier to
>>> implement this as an eselect module then, as opposed to creating a
>>> bunch of separate profiles?
> 
>> profiles handle USE flags, eselect does not. Of course, you can use
>> eselect to change profiles :)
>>
>> It's not as complex as creating a lot of different systemd profiles
>> because of inheritance.
> 
> Thanks Neil, but... what are you suggesting then? That it would have to
> be done as profiles, but it wouldn't be really complicated? Or maybe
> that it would be a combination of profile selection and... something
> else (new eselect init module)?
> 
> Remember, I want all of this to coalesce into an enhancement/feature
> request for gentoo to be able to provide a sound, sane way to manage the
> idea of switching init systems.

eselect is not going to work and neither is a Gentoo profile.

eselect manages config options between different implementation of a
thing. Usually by tweaking symlinks. Switching init OpenRC <-> SystemD
involves resetting uSE flags and recompiling some fundamental stuff.
That exercise is unlikely to ever go into eselect.

The devs on gentoo-dev already nuked the idea of a gentoo profile as
such, it's not worth the effort and causes an explosion of profiles.

Switching to and from systemd is a few simple steps:

- Change some USE
- Recompile some stuffs
- maybe read a howto or two
- in all likelihood reboot



Conceptually, it is rather similar to switching between nouveau and
nvidia. That doesn't have eselect support[1] or profiles.


To switcvh to and from
>>> I'd also suggest throwing in a test for current running kernel config,
>>> to make sure it fully supports booting with systemd, and maybe a new
>>> emerge command that can also be maintained to make sure that *all*
>>> necessary packages are rebuilt?
> 
>> That's already taken care of, the systemd ebuild checks your kernel
>> config as part of the pre-emerge checks, nothing happens until you have a
>> suitable kernel.
> 
> Ok, excellent...
> 
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sat, Feb 22, 2014 at 9:28 AM, Andrew Savchenko <bircoph@gmail.com> wrote:
[snip]
> And here we have a design issue. I already pointed this issue in this
> discussion:
> http://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg144144.html
> Though it was completely ignored by you. I understand: it is easier
> to discuss design in terms of taste than in technical merits.

I'm sorry, I was not part of that particular subthread. You are wrong
anyway (see below)

> Systemd assumes that time required to start service is small (at
> microseconds scale). While this is true for widely used simple
> setups, this is not true in general case. Service may take seconds or
> even minutes to start up (good example are services depending on
> enterprise SAN or large databases).

Yeah; and systemd needs not to worry about that. The clients
connecting have to. Set the clients to wait a reasonable time, and
then everybody is happy.

> And because systemd never assumes
> it can take long time to start we have the following issues possible
> in general case:
>
> 1. Client connections are lost due to timeout when service takes
> long time to start. Systemd fakes service to be available while it
> isn't still. Thus systemd is not an option for production grade
> servers.

Again, you can configure that on the clients.

> 2. Even if connection timeout is not reached, requests may pale up and
> be lost. Loss trigger depends on memory available, thus systemd is
> not an option for both embedded setups and production server setups.

You realize that if it's embedded, it makes no sense that it receives
the godzillion connections necessary for the kernel queue to fill up?
And on big iron, you can define the size of the queue; in the kernel,
again, this has nothing to do with systemd. You don't even need to
recompile your kernel.

> As one can see, while systemd socket activation design will work for
> many case,

Glad to see you at least recognize this; but it can work for all
cases. It doesn't have to, though (see below).

> it will fail for corner ones and by no means can't be used
> in production (where this corner cases have a high chance to rise).

You evidently have no idea what are you talking about.

First of all, as I said, the "problems" you mention are not problems
at all, since slow starting services, by definition, have clients that
need to cope with the slow starting (and if they don't, it's a bug in
the clients); and because either you are embedded, and therefore you
don't expect a godzillion connections, or you are medium size or big
iron, and you set your queue size with a kernel knob to be as large as
necessary.

And secondly, even if those problems were real (which they are not),
socket activation *IS OPTIONAL*. It's a feature that systemd supports,
*if the admin wants to use it*. If you are in a corner case and you
cannot change the timeout of your clients (because they are
proprietary, for example), or you are constrained by memory (if you
are embedded but anyhow want to handle gracefully a godzillion
connections), THEN YOU DON'T USE SOCKET ACTIVATION.

"Problem" solved.

If you are *really* interested in learning about the advantages of
socket activation, read [1]. However, I'm sure that you will not, as
time and again in this thread you only have show that you are not even
willing to do your homework before you start ranting against systemd;
just like you did when you said that libsystemd.so was used in PID 1
[2] (which, of course, you conveniently ignored although I replied
specifically to you).

Therefore, I'm not going to waste more of my time arguing with someone
who doesn't even read the proper documentation.

I'm done with you in this thread.

Regards.

[1] http://0pointer.de/blog/projects/socket-activation.html
[2] http://article.gmane.org/gmane.linux.gentoo.user/272840
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 22.02.2014 21:21, Stroller wrote:
>
> On Sat, 22 February 2014, at 10:38 am, Yuri K. Shatroff
> <yks-uno@yandex.ru> wrote:
>
>> On 22.02.2014 11:40, Mark David Dumlao wrote:
>>> [ ... ] Even as the complex beast it has become systemd is still
>>> simpler than the alternative of having abominations of unreliable
>>> shell scripts checking to see which version of grep and sed is
>>> used to split the command line, or whether the system uses
>>> tempfile or mktemp, or depending on perl.
>>
>> Well, simpler yeah, supporting only one kernel of specific versions
>> is always simpler than trying to support everything from SunOS to
>> NetBSD. This way, if the kernel supported only e.g. Intel
>> IvyBridge+ with one chipset family, one graphics (VESA) and so on,
>> it would have been incredibly simpler.
>
> I’m doing a (free) operating system (just a hobby, won’t be big and
> professional like gnu) for 386(486) AT clones. … PS. Yes – it’s free
> of any minix code, and it has a multi-threaded fs.  It is NOT
> protable (uses 386 task switching etc), and it probably never will
> support anything other than AT-harddisks, as that’s all I have :-(.

Good luck!

> Linux did indeed once support only one CPU family and one or two
> hard-drives, and the reason that it now supports more is that people
> dug into the code, submitted patches and got it fixed.
>
> Had all the original Linux developers spent their time on the
> comp.os.minix list, complaining "oh, those splitters, they're trying
> to fragment the Minix community" and "this Linus guy should be
> putting his effort into improving the Minix kernel", where would we
> be today?

Actually I don't get what you are arguing [against].

> It's almost hilarious the volume of traffic expended here on this
> subject, especially that by the naysayers. When I first learned of
> systemd I did not feel favourably towards it, but those ranting
> against it have only given Canek a platform to convince me.

I partially agree. In an emotional discussion the most probable winner 
(as seen from outside) is the calm one.
But being calm doesn't refute all technical and `political` stuff.
I personally was going to try systemd about a week ago when the 
discussion started. Now I'm quite convinced not to do this in the near 
future.
No calm arguments of systemd's supporters, such as the complexity of 
shell scripts, the simplicity of systemd compared to the Kernel, the 
ease of use of journald tools, the shitload of troubles of configuring 
syslog, the replacement for all network setup tools, the good intents of 
Red Hat, etc etc, didn't convince me. Emotions pass, results remain.

> And whilst I'm still of two minds on which init system I'd ideally
> prefer, I am not under any delusions that I can influence the
> developers of the Gentoo distro or those of the Linux kernel (who
> AIUI are adding kdbus to support systemd), either by ranting about it
> here or otherwise.

No delusions, there will always be an alternative.
Nobody actually has disagreed yet with my words that in a couple of 
years systemd is going to dominate "90%" (meaning the majority of) linux 
distros. But "10%" hopefully will remain without it. Anyway since 
systemd is not intending to support any other kernels, we'll probably 
see other OS or stuff like Debian/kFreeBSD develop more intensively.
Yet, of course, these alternatives will necessarily be poorer supported 
and one will have to take effort to migrate - to either the distro he 
used, but the version with systemd, or a different distro/OS.

> The amount of energy spent on this, you could have established a fork
> and written code by now - if y'all really want to prove your point,
> that's the way to do it.

What point?
I personally am terribly satisfied with the SysV init and shell scripts 
so what am I to fork and write?
What a fork to establish? A fork of debian, to maintain it w/o systemd? 
Let that be done by debianners maybe, if they so desire.

As for `ranting`, I do see a point in such talks (until these get 
personal), as I learn many new things (both from the posts and while 
trying to prove/refute the points) and I always try to ask a concrete 
question and answer a concrete question. Note: I do repeat *I* here 
because you answered *my* post.

In any case, no offense, your reply is a rant, too.

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sat, Feb 22, 2014 at 1:36 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> On 22.02.2014 21:21, Stroller wrote:

[ snip ]

>> I’m doing a (free) operating system (just a hobby, won’t be big and
>> professional like gnu) for 386(486) AT clones. … PS. Yes – it’s free
>> of any minix code, and it has a multi-threaded fs.  It is NOT
>> protable (uses 386 task switching etc), and it probably never will
>> support anything other than AT-harddisks, as that’s all I have :-(.
>
> Good luck!

Please, tell me this is sarcasm, and that you know that Stroller was
quoting Linus' historical announcement (ca. 1991) of what eventually
become the Linux kernel[1].

Regards.

[1] http://www.thelinuxdaily.com/2010/04/the-first-linux-announcement-from-linus-torvalds/

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 23.02.2014 00:22, Canek Peláez Valdés wrote:
> On Sat, Feb 22, 2014 at 1:36 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
>> On 22.02.2014 21:21, Stroller wrote:
>
> [ snip ]
>
>>> I’m doing a (free) operating system (just a hobby, won’t be big and
>>> professional like gnu) for 386(486) AT clones. … PS. Yes – it’s free
>>> of any minix code, and it has a multi-threaded fs.  It is NOT
>>> protable (uses 386 task switching etc), and it probably never will
>>> support anything other than AT-harddisks, as that’s all I have :-(.
>>
>> Good luck!
>
> Please, tell me this is sarcasm, and that you know that Stroller was
> quoting Linus' historical announcement (ca. 1991) of what eventually
> become the Linux kernel[1].

Well you sort of cracked it, but I'd rather wait for Stroller's 
response, esp. to this:

 > Actually I don't get what you are arguing [against].


-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 8322 bytes --]

On Monday 17 Feb 2014 07:01:53 Yuri K. Shatroff wrote:
> 17.02.2014 00:19, Canek Peláez Valdés пишет:
> > On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff <yks-uno@yandex.ru>
> > wrote: [ snip ]
> > 
> >> Isn't there too many "if you believe" and "if you agree"? A church of
> >> systemd? ;)
> > 
> > As I said to Tanstaafl, it gets kind of philosophical.
> 
> Even religious.
> 
> > Technically, systemd is the obvious superior choice, and that's why
> > the TC voted for it in Debian (read the discussion).
> 
> Oh I have read so many discussions already... :)
> To me, systemd's technical superiority is far not obvious. Just another
> init system would be, but as long as systemd is much more that one, I
> can't say that. It should NOT be compared to OpenRC / upstart alone,
> rather to a whole bunch of tools it replaces, and probably even those
> it's ambitious to replace.
> 
> >> I wonder why all systemd's fancy stuff hasn't yet been integrated into
> >> any existing init system, because of theoretical impossibility or just
> >> practical uselessness?
> > 
> > If it's "practically useless", why so many distributions keep choosing
> > it? Why GNOME started using it?
> 
> Well, I said that technical superiority matters little for maintainers;
> what matters is money. If I'd write some super-puper fancy init system
> and kernel replacement, who would be interested? It's not the time of
> Linus' rise, now you don't deal with USENET freaks, but with Intel,
> RedHat and other billionaire corps. Do you have the guts and means to
> keep up with competitors, even not about kernel/init subsystems, but a
> user app like mailer/browser/messenger...
> A kernel subsystem requires much more technical competence to maintain
> and is far more critical for functioning, so much more important here is
> not any 'technical superiority' but simply resources, human and
> financial, spared if using RH-maintained systemd.
> 
> >> Actually why not do the daemon management, logging, cron etc in the
> >> Linux kernel itself? It's obvious, and we even have a perfect example
> >> of kernel-integrated graphics around -- `guess the OS name`. It also
> >> has much in common with systemd; "Believe us it's the best OS",
> >> "Believe us it provides loads of features", "Agree with having binary
> >> logs" etc.
> > 
> > All the software is libre; with only that any comparison to Microsoft
> > becomes moot.
> 
> Once you mentioned "technical superiority", let's compare other stuff
> technically too. :)
> 
> >> A competent approach for choosing software for a task is answering the
> >> questions:
> >> 1. Is the software standards-compliant?
> >> 2. Does the software have an alternative compatible implementation?
> >> 3. Is the software developed to achieve a certain, concrete goal?
> >> 4. Does the software achieve the goal?
> >> 5. Does the software achieve the goal "gracefully"?
> >> 6. Does the software have a clear perspective and view what it will be
> >> like? 7. Is the software developed and maintained by a reliable company
> >> or group?
> > 
> > That's *your* approach. It's certainly not my approach: I don't care
> > if Emacs is "standards-compliant" (whatever that means for a text
> > editor); I don't care if Inkscape has an alternative compatible
> > implementation; and for the rest of your questions, my answer would be
> > yes.
> 
> You don't care about Emacs and Inkscape but do you care the same nought
> about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks
> HTTP rather than SHiTP? Do you care that once after a couple of years
> your systems get unmaintained and unmaintainable because the software on
> them becomes a load of bashed up crap which only a world's head lennart
> can deal with? Well, you'll say that red hat tralala, but we've seen the
> rise and fall of many giants e.g. Sun with their once 'technically
> superior' Solaris and SPARCs, well one can name many I just don't have
> time, also we seen MySQL bought by Oracle, and all.
> Nothing is eternal, and it's (Again!) quite not always technical matters
> that matters.
> 
> >> AFAICT, with systemd there's by far one "yes". The other answers are
> >> dubious if just plain "no".
> >> 
> >  From your point of view.
> >  
> >> I'd personally share Alan McKinnon's POV: there's no real reason to
> >> switch to systemd since the present init systems serve pretty well and
> >> the benefit, if any, isn't worth the adaptation threshold.
> > 
> > That's fine; you don't have to use systemd. But if (as an extreme and
> > unlikely example), Gentoo decided to switch exclusively to systemd,
> > then either someone willing and able would need to come out ant start
> > maintaining the alternatives, or then you should do it.
> 
> At present, no. But the trend is clear.
> 
> > That's how free software works.
> 
> Actually, free software (one you don't pay for) works like any other
> software you pay for. You probably wanted to say "that's how the OSS
> model works" but it's getting less and less true. The OSS model in many
> cases retains only its open source. Take MySQL, take KDE, take GNOME.
> Who cares about users? We do what we deem feasible regardless if you
> like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's
> technically superior. C'mon, who are you? An admin? A programmer? A
> Bachelor/PhD? Ha, man, we're BILLIONAIRES. That says it. We GRANT you
> our software AS IS. And its source. And its bugtrackers. We make
> business by the fact that we have millions of free testers 'round the
> world. We can afford that. If you can afford forking and maintaining,
> c'mon man.
> 
> >> But why then is Linux drifting to systemd? The answer is simple: money.
> >> Time is money. You have to support two init systems -> twice the time,
> >> twice the money. Sooner or later, a sum of money will outweigh the
> >> users' opinion. To be a realist, one has to admit that in near future
> >> 90% of new distro versions will be systemd-based. Unless some green
> >> soxx emerge and take over Red Hat...
> > 
> > I don't think neither time nor money had to do with Debian's (nor
> > Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision.
> 
> It's not in terms "think" or "don't think". It's a fact.
> 
> > It's just technically superior. But's that's just my opinion, and what
> > I believe ;)
> 
> That's a good thing to believe in. It's hard to prove, hard to see,
> impossible to test all cases.
> Money is what you don't believe in. You either have it enough or not.
> 
> > So, amen? :D
> 
> Amen. :D
> 
> > Regards.

I am not sure if people object to the Lennart-way of messing up Linux, under 
the blessings of RHL, or if they just don't like the immediate outcome.

Essentially, in his arrogance Lennart only needs to code things the way *he* 
sees as useful or expedient to him and his pay masters.  In doing so he throws 
the *nix way of developing software out of the window and creates a convenient 
for him monolith.  Wherever he can't be bothered to do a neat and versatile 
job he makes his own arguably option-limiting decisions and thus we have 
arrived to today's flavour of systemd-udev-pulseaudio-gnome and whatever else 
he will try to weld in tomorrow.  He found like minds in Sievers et al and 
money from RHL helped them get there.

It ain't pretty and architecturally does not follow the *nix design 
principles, but as Canek says, those who can code better should step up to the 
plate and redesign systemd as it should have been done from the start for the 
benefit of Linux, without making the design compromises that Lennart has 
decided suit him.  I don't know if forking systemd is easy, but no one has so 
far decided to do so.

Given the title of this thread I fear that those of us who can't code, will 
increasingly find our choices becoming limited, because more and more 
functionality is hacked inextricably into systemd and friends.  It's probably 
too early to call if Gentoo will remain one of the few options in Linux that 
do not use systemd, but decisions taken upstream (for example initrd for 
separate /usr) are affecting some us already.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 23, 2014 at 7:35 AM, Mick <michaelkintzios@gmail.com> wrote:
[ snip ]
> I am not sure if people object to the Lennart-way of messing up Linux, under
> the blessings of RHL, or if they just don't like the immediate outcome.

Actually, most people that actually *try* using systemd and reads how
it works have no problems with it, and of those there are many (like
me) who actually quite like it.

> Essentially, in his arrogance Lennart only needs to code things the way *he*
> sees as useful or expedient to him and his pay masters.  In doing so he throws
> the *nix way of developing software out of the window and creates a convenient
> for him monolith.  Wherever he can't be bothered to do a neat and versatile
> job he makes his own arguably option-limiting decisions and thus we have
> arrived to today's flavour of systemd-udev-pulseaudio-gnome and whatever else
> he will try to weld in tomorrow.  He found like minds in Sievers et al and
> money from RHL helped them get there.

And he also found like minds in some of the kernel developers, and
some people from OpenSUSE, and Arch, and Debian, and Gentoo, and even
Ubuntu, and old Linux gurus like Keith Packard and Neil Brown[1].

> It ain't pretty and architecturally does not follow the *nix design
> principles, but as Canek says, those who can code better should step up to the
> plate and redesign systemd as it should have been done from the start for the
> benefit of Linux, without making the design compromises that Lennart has
> decided suit him.  I don't know if forking systemd is easy, but no one has so
> far decided to do so.

I don't think forking would attract much developers. Writing something
new trying to follow "the*nix design principles", but being modern and
with the same features (all of them optional, of course) of systemd
will have more chances; although I think it will fail because most of
the people that can code "better" actually like the systemd design,
and would prefer to contribute to it.

And if you found enough of this mythical good-coders, good luck
defining what it means "the*nix design principles".

> Given the title of this thread I fear that those of us who can't code, will
> increasingly find our choices becoming limited, because more and more
> functionality is hacked inextricably into systemd and friends.  It's probably
> too early to call if Gentoo will remain one of the few options in Linux that
> do not use systemd, but decisions taken upstream (for example initrd for
> separate /usr) are affecting some us already.

First of all, Gentoo uses systemd if the user so desires (like I do).

Secondly, no one has proposed (AFAIK) systemd as the default init
system for Gentoo, and I don't think no one will in the short term
future.

And to finish, the fact is that people are using systemd because it
works, the design if good (it can be improved, of course; everything
can), and it has attracted a really large flock of talented developers
around it.

No other option offers any interest for people trying to develop new
cool things and design new standards; the only similar (albeit much
more limited in scope) alternative was Upstart, and I personally don't
think it will be maintained for much longer, except for bugs and
security vulnerabilities; it will have no new features.

In general the people not wanting to use systemd don't even care about
its features; they only want the good old SysV (or OpenRC here in
Gentoo), and that nobody touches their systems.

Since OpenRC is the default in Gentoo, and I don't think that will
change anytime soon, they can have that.

Regards.

[1] http://lwn.net/Articles/584176/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 23/02/2014 20:18, Canek Peláez Valdés wrote:
> I don't think forking would attract much developers. Writing something
> new trying to follow "the*nix design principles", but being modern and
> with the same features (all of them optional, of course) of systemd
> will have more chances; although I think it will fail because most of
> the people that can code "better" actually like the systemd design,
> and would prefer to contribute to it.
> 
> And if you found enough of this mythical good-coders, good luck
> defining what it means "the*nix design principles".


I've been wondering about this concept of "the*nix design principles"...

I've now concluded it's a myth, much like invisible pink unicorns.

Is it like the kernel? A huge monolithic chunk of code with support for
modules?
Is it like X11? A huge monolithic chunk of code that has a bizarre build
system for years, and took something like 5 years of hard work to get it
modular? And is 20 years behind the times? And *still* requires devs to
jump through hoops to get a rendered image through a compositor and back
up the the GPU?
Is it like perl? Support every possible way to do something if it
remotely makes sense to do it, no matter how bizarre the syntax?
Is it like python? Pick ONE way to do it and stick with it dammit!
Is it like php? Do whatever you feel like?
Is it like command line text processing tools that only do one narrow
thing well? [1]
Is it like bash? I can't find a decent description of how bash came to
be except it's like Vogons - wasn't designed and didn't evolve, it just
sort of ... congealed

Not to rain on anyone's parade, but there's a prize of 40 internets up
for the first person who can clearly and unambiguously define "Unix
design principles" with specificity so that it is globally applicable.

Best I can come up with is "Use common sense and build stuff that can be
used and maintained" which is wonderfully descriptive but really sucks
as a definition.



[1] For lack of a better term, let's just call systemd here a "system
controller". What is this ONE thing a system controller should do and do
it well?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 23, 2014 at 4:32 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
>> I don't think forking would attract much developers. Writing something
>> new trying to follow "the*nix design principles", but being modern and
>> with the same features (all of them optional, of course) of systemd
>> will have more chances; although I think it will fail because most of
>> the people that can code "better" actually like the systemd design,
>> and would prefer to contribute to it.
>>
>> And if you found enough of this mythical good-coders, good luck
>> defining what it means "the*nix design principles".
>
> I've been wondering about this concept of "the*nix design principles"...
>
> I've now concluded it's a myth, much like invisible pink unicorns.

Exactly.

> Is it like the kernel? A huge monolithic chunk of code with support for
> modules?
> Is it like X11? A huge monolithic chunk of code that has a bizarre build
> system for years, and took something like 5 years of hard work to get it
> modular? And is 20 years behind the times? And *still* requires devs to
> jump through hoops to get a rendered image through a compositor and back
> up the the GPU?
> Is it like perl? Support every possible way to do something if it
> remotely makes sense to do it, no matter how bizarre the syntax?
> Is it like python? Pick ONE way to do it and stick with it dammit!
> Is it like php? Do whatever you feel like?
> Is it like command line text processing tools that only do one narrow
> thing well? [1]
> Is it like bash? I can't find a decent description of how bash came to
> be except it's like Vogons - wasn't designed and didn't evolve, it just
> sort of ... congealed
>
> Not to rain on anyone's parade, but there's a prize of 40 internets up
> for the first person who can clearly and unambiguously define "Unix
> design principles" with specificity so that it is globally applicable.
>
> Best I can come up with is "Use common sense and build stuff that can be
> used and maintained" which is wonderfully descriptive but really sucks
> as a definition.

I reached a similar conclusion; "Unix principles" is, basically,
whatever good idea you can have for a particular problem. Therefore,
almost anything under the sun can be reasonably argued to be following
"Unix principles". In particular, all of the examples you listed.

"Unix principles" says nothing, means nothing, and helps even less to
design anything.

Almost all the people criticizing systemd or Wayland are Unix *users*,
not *developers*. Most Unix/Linux *developers* (not package
maintainers) actually like the changes introduced by systemd and/or
Wayland; of those who not, most of them at least *understand* why a
change was necessary (and long overdue). A minority oppose those
changes vehemently; but at this point, I'm starting to question if
that opposition has technical foundations, or if it's just a gut
reaction to an specific set of developers and/or companies.

> [1] For lack of a better term, let's just call systemd here a "system
> controller". What is this ONE thing a system controller should do and do
> it well?

Control the system?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 3471 bytes --]

On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote:
> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
> > I don't think forking would attract much developers. Writing something
> > new trying to follow "the*nix design principles", but being modern and
> > with the same features (all of them optional, of course) of systemd
> > will have more chances; although I think it will fail because most of
> > the people that can code "better" actually like the systemd design,
> > and would prefer to contribute to it.
> > 
> > And if you found enough of this mythical good-coders, good luck
> > defining what it means "the*nix design principles".
> 
> I've been wondering about this concept of "the*nix design principles"...

Well, I'm no authority on this since I can't code, but here's a starter for 
10:

  http://www.faqs.org/docs/artu/ch01s06.html

  http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html

  http://en.wikipedia.org/wiki/Unix_philosophy


> I've now concluded it's a myth, much like invisible pink unicorns.
> 
> Is it like the kernel? A huge monolithic chunk of code with support for
> modules?

I would think that although the kernel has grown over the years, it has not 
done so like systemd.  You can still *not* build modules you don't need in 
your kernel.


> Is it like X11? A huge monolithic chunk of code that has a bizarre build
> system for years, and took something like 5 years of hard work to get it
> modular? And is 20 years behind the times? And *still* requires devs to
> jump through hoops to get a rendered image through a compositor and back
> up the the GPU?

The X11 devs saw the error of their ways and ended up breaking up the big 
monolithic Xorg code and releasing it as a modular package since X11 7.0, if I 
recall right.


> Is it like perl? Support every possible way to do something if it
> remotely makes sense to do it, no matter how bizarre the syntax?
> Is it like python? Pick ONE way to do it and stick with it dammit!
> Is it like php? Do whatever you feel like?
> Is it like command line text processing tools that only do one narrow
> thing well? [1]
> Is it like bash? I can't find a decent description of how bash came to
> be except it's like Vogons - wasn't designed and didn't evolve, it just
> sort of ... congealed

Designing a programming language is not exactly parallel with designing an OS, 
although similarities exist (e.g. re-use code where you can and don't re-
invent the wheel).


> Not to rain on anyone's parade, but there's a prize of 40 internets up
> for the first person who can clearly and unambiguously define "Unix
> design principles" with specificity so that it is globally applicable.

The Unix design philosophy may not be globally applicable, but has served 
Linux well over the years.  Lennart has de facto introduced a different way of 
developing his Linux code, which to others and me seems more restrictive.  I 
am not saying that his coding is poor (I'm not qualified to judge), or that 
systemd is wholesale bad.  But, is this a whole new design paradigm in the 
development of Linux that we should applaud and follow, or just a mistake 
borne out of ignorance/arrogance/expedience?

Time will tell.


> [1] For lack of a better term, let's just call systemd here a "system
> controller". What is this ONE thing a system controller should do and do
> it well?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@gmail.com> wrote:

[ snip ]

> Well, I'm no authority on this since I can't code,

My point exactly.

> but here's a starter for  10:
>
>   http://www.faqs.org/docs/artu/ch01s06.html

Funny you mention this; the second definition is by Robert Pike, who later said:

"Not only is UNIX dead, it's starting to smell really bad."

>   http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html

You can hear in [2] the best response to the famous quote by Henry
Spencer ("Those who don't understand UNIX are doomed to reinvent it,
poorly."):

"Those who don't understand UNIX are condemned to quote Henry Spencer."

And that's the point; the people doing this changes *obviously
understand Unix*. They understand it so well that they are able to
look at it honestly, beyond dogma or articles of faith, and see its
downsides, so they can try to fix them.

>   http://en.wikipedia.org/wiki/Unix_philosophy

This reminds me of the people that quote from religious books to argue
about anything non theological. The "rules" and "sound bites" in the
links you provide are there to summarize rules of thumb; they are NOT
scripture, and they are certainly NOT the only way to get a
technically good program that is easily maintainable. In other words,
you can ignore most of them, or just following them to a point, and
anyway end up with a sound design and a technically great program that
is easy to maintain and extend.

The people with coding experience (or most of them anyway) understand
this; we are not a religion, we don't have prophets that speak the
undeniably truth. We have highly skilled developers who can have
opposing views on how to design and implement many different ideas,
and that doesn't (necessarily) means that any of them are wrong.

There are many ways to solve a problem of sets of problems. Having
Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is
"wrong", nor the other way around.

>> I've now concluded it's a myth, much like invisible pink unicorns.
>>
>> Is it like the kernel? A huge monolithic chunk of code with support for
>> modules?
>
> I would think that although the kernel has grown over the years, it has not
> done so like systemd.  You can still *not* build modules you don't need in
> your kernel.

This has nothing to do with "Unix principles"; it's just that someone
willing and able implemented the different options.

>> Is it like X11? A huge monolithic chunk of code that has a bizarre build
>> system for years, and took something like 5 years of hard work to get it
>> modular? And is 20 years behind the times? And *still* requires devs to
>> jump through hoops to get a rendered image through a compositor and back
>> up the the GPU?
>
> The X11 devs saw the error of their ways and ended up breaking up the big
> monolithic Xorg code and releasing it as a modular package since X11 7.0, if I
> recall right.

The X11 devs decided that X11 is crap, and therefore they are working
now in Wayland. Yes, Wayland is basically written by the same people
who maintains X.org. Again, see [2], it's pretty awesome.

>> Is it like perl? Support every possible way to do something if it
>> remotely makes sense to do it, no matter how bizarre the syntax?
>> Is it like python? Pick ONE way to do it and stick with it dammit!
>> Is it like php? Do whatever you feel like?
>> Is it like command line text processing tools that only do one narrow
>> thing well? [1]
>> Is it like bash? I can't find a decent description of how bash came to
>> be except it's like Vogons - wasn't designed and didn't evolve, it just
>> sort of ... congealed
>
> Designing a programming language is not exactly parallel with designing an OS,
> although similarities exist (e.g. re-use code where you can and don't re-
> invent the wheel).

I'm pretty sure there are lots of people who vehemently believe that
the "Unix principles" can apply to everything, even programming
languages. You would be cataloged as an heretic for saying that is not
exactly parallel.

>> Not to rain on anyone's parade, but there's a prize of 40 internets up
>> for the first person who can clearly and unambiguously define "Unix
>> design principles" with specificity so that it is globally applicable.
>
> The Unix design philosophy may not be globally applicable, but has served
> Linux well over the years.

No; what has served Linux is to have developers willing and able to
write the necessary code, following whatever design they decide is the
correct one.

> Lennart has de facto introduced a different way of
> developing his Linux code, which to others and me seems more restrictive.

First of all, it's not only Lennart; the systemd repo has (literally)
dozens of contributors with write access.

Second of all, calling "restrictive" the tightly integrated approach,
is exactly as constructive as calling "anarchic" the loosely
integrated one. Like "Unix principles", it means nothing and it says
nothing.

> I am not saying that his coding is poor (I'm not qualified to judge), or that
> systemd is wholesale bad.  But, is this a whole new design paradigm in the
> development of Linux that we should applaud and follow, or just a mistake
> borne out of ignorance/arrogance/expedience?

Or people willing and able to try new ideas that they believe are awesome?

> Time will tell.

Indeed; although, as I see, time is already telling us.

Regards.

[1] http://proness.kix.in/talks/foss.in07-plan9.pdf
[2] http://www.youtube.com/watch?v=F6PFjoYuml0&t=28m27s
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 24/02/2014 01:12, Mick wrote:
> On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote:
>> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
>>> I don't think forking would attract much developers. Writing something
>>> new trying to follow "the*nix design principles", but being modern and
>>> with the same features (all of them optional, of course) of systemd
>>> will have more chances; although I think it will fail because most of
>>> the people that can code "better" actually like the systemd design,
>>> and would prefer to contribute to it.
>>>
>>> And if you found enough of this mythical good-coders, good luck
>>> defining what it means "the*nix design principles".
>>
>> I've been wondering about this concept of "the*nix design principles"...
> 
> Well, I'm no authority on this since I can't code, but here's a starter for 
> 10:
> 
>   http://www.faqs.org/docs/artu/ch01s06.html
> 
>   http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html

I really like documents like this, all airy-fairy and giving the
impression that the whole design was worked out nicely in advance. It
wasn't. the doc even quotes this fellow who had nothing to do with the
doc itself:

"Those who don't understand UNIX are doomed to reinvent it, poorly."
--Henry Spencer

Let me tell you how Unix was designed, how the whole thing took shape
once K&R had gotten C pretty much stabilized. It is most apparent in IO
error handling in early designs and it goes like this:

We don't do error handling. We don't even try and deal with it at the
point it occurred, we just chuck it back up the stack, essentially
giving them message "stuff it, I'm not dealing with this. You called me,
you fix it."

Doesn't sound like good design does it? Sounds more like do whatever you
think you can get away with. Good design in this area gives you
something conceptually along the lines of try...catch...finally (with
possibly some work done to avoid throwing another exception in the
finally). Unix error "design" does this:

exit <some arb number>
and an error message is in $@ if you feel like looking for it

Strangely, this approach is exactly why Unix took off and got such
widespread adoption throughout the 70s. An engineer will understand that
a well-thought out design that is theoretically correct requires an
underlying design that is consistent. In the 70s, hardware consistency
was a joke - every installation was different. Consistent error handling
would severely limit the arches this new OS could run on. By taking a
"Stuff it, you deal with it coz I'm not!" approach, the handling was
fobbed off to a higher layer that was a) not really able to deal with it
and b) at least in a position to try *something*.

By ripping out the theoretical correctness aspects, devs were left with
something that actually could compile and run. You had to bolt on your
own fancy bits to make it reliable but eventually over time these things
too stabilized into a consistent pattern (mostly by hardware vendors
going bankrupt and their stuff leaving the playing field)

And so we come to what "Unix design" probably really is:

"You do what you have to to get the job done, the simpler the better,
but I'm not *really* gonna hold you to that."

I still don't like what Lennart has done with this project, but I also
fail to see what design principle he has violated.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Walter Dnes]

On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote

> We don't do error handling. We don't even try and deal with it at the
> point it occurred, we just chuck it back up the stack, essentially
> giving them message "stuff it, I'm not dealing with this. You called me,
> you fix it."

  The developer is not going to be psychic to the point of knowing what
the user *WANTED* to do, years after the code was written... or which
different users were expecting which different outcomes.  E.g. if
portage encounters a problem during a build, do you *REALLY* want it to
jump in and randomly patch source code and/or makefiles to get it
working?  NO!!! You want it to halt, with an informative error message,
possibly including suggestions for corrective action.  If I mistakenly
tell a system to do B, really meaning do A, that's my fault.  If I tell
it to do A, and it decides to do B, I will be extremely p'd off.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote
>
>> We don't do error handling. We don't even try and deal with it at the
>> point it occurred, we just chuck it back up the stack, essentially
>> giving them message "stuff it, I'm not dealing with this. You called me,
>> you fix it."
>
>   The developer is not going to be psychic to the point of knowing what
> the user *WANTED* to do, years after the code was written... or which
> different users were expecting which different outcomes.  E.g. if
> portage encounters a problem during a build, do you *REALLY* want it to
> jump in and randomly patch source code and/or makefiles to get it
> working?  NO!!! You want it to halt, with an informative error message,
> possibly including suggestions for corrective action.

But in Unix you usually don't halt, you set errno and go on your merry way.

>  If I mistakenly
> tell a system to do B, really meaning do A, that's my fault.  If I tell
> it to do A, and it decides to do B, I will be extremely p'd off.

I don't see what does that have to do with any of Alan's points.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Mon, Feb 24, 2014 at 9:07 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 24/02/2014 01:12, Mick wrote:
>> On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote:
>>> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
>>>> I don't think forking would attract much developers. Writing something
>>>> new trying to follow "the*nix design principles", but being modern and
>>>> with the same features (all of them optional, of course) of systemd
>>>> will have more chances; although I think it will fail because most of
>>>> the people that can code "better" actually like the systemd design,
>>>> and would prefer to contribute to it.
>>>>
>>>> And if you found enough of this mythical good-coders, good luck
>>>> defining what it means "the*nix design principles".
>>>
>>> I've been wondering about this concept of "the*nix design principles"...
>>
>> Well, I'm no authority on this since I can't code, but here's a starter for
>> 10:
>>
>>   http://www.faqs.org/docs/artu/ch01s06.html
>>
>>   http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html
>
> I really like documents like this, all airy-fairy and giving the
> impression that the whole design was worked out nicely in advance. It
> wasn't. the doc even quotes this fellow who had nothing to do with the
> doc itself:
>
> "Those who don't understand UNIX are doomed to reinvent it, poorly."
> --Henry Spencer
>
> Let me tell you how Unix was designed, how the whole thing took shape
> once K&R had gotten C pretty much stabilized. It is most apparent in IO
> error handling in early designs and it goes like this:
>
> We don't do error handling. We don't even try and deal with it at the
> point it occurred, we just chuck it back up the stack, essentially
> giving them message "stuff it, I'm not dealing with this. You called me,
> you fix it."
>
> Doesn't sound like good design does it? Sounds more like do whatever you
> think you can get away with. Good design in this area gives you
> something conceptually along the lines of try...catch...finally (with
> possibly some work done to avoid throwing another exception in the
> finally). Unix error "design" does this:
>
> exit <some arb number>
> and an error message is in $@ if you feel like looking for it
>
> Strangely, this approach is exactly why Unix took off and got such
> widespread adoption throughout the 70s. An engineer will understand that
> a well-thought out design that is theoretically correct requires an
> underlying design that is consistent. In the 70s, hardware consistency
> was a joke - every installation was different. Consistent error handling
> would severely limit the arches this new OS could run on. By taking a
> "Stuff it, you deal with it coz I'm not!" approach, the handling was
> fobbed off to a higher layer that was a) not really able to deal with it
> and b) at least in a position to try *something*.
>
> By ripping out the theoretical correctness aspects, devs were left with
> something that actually could compile and run. You had to bolt on your
> own fancy bits to make it reliable but eventually over time these things
> too stabilized into a consistent pattern (mostly by hardware vendors
> going bankrupt and their stuff leaving the playing field)
>
> And so we come to what "Unix design" probably really is:
>
> "You do what you have to to get the job done, the simpler the better,
> but I'm not *really* gonna hold you to that."
>

*slow clap*

-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Poison BL.]

On Sun, Feb 23, 2014 at 9:20 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> On Sun, Feb 23, 2014 at 8:10 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > On Mon, Feb 24, 2014 at 03:07:09AM +0200, Alan McKinnon wrote
> >
> >> We don't do error handling. We don't even try and deal with it at the
> >> point it occurred, we just chuck it back up the stack, essentially
> >> giving them message "stuff it, I'm not dealing with this. You called me,
> >> you fix it."
> >
> >   The developer is not going to be psychic to the point of knowing what
> > the user *WANTED* to do, years after the code was written... or which
> > different users were expecting which different outcomes.  E.g. if
> > portage encounters a problem during a build, do you *REALLY* want it to
> > jump in and randomly patch source code and/or makefiles to get it
> > working?  NO!!! You want it to halt, with an informative error message,
> > possibly including suggestions for corrective action.
>
> But in Unix you usually don't halt, you set errno and go on your merry way.
>

Actually, from everything I've seen (and it's at least true throughout
what I've worked with in glibc) you *do* stop dead in your tracks, set
errno, and return some (hopefully indicative of a possible error)
value. In the case of standalone executables rather than library
calls, you stop where you are, if you're feeling generous you output
something to stderr on the way out the door, then exit(errno). The
process that called *you* then goes on its merry way, handling your
response of "Hey, something went wrong. Good luck." however it
chooses, if it chooses to.

> >  If I mistakenly
> > tell a system to do B, really meaning do A, that's my fault.  If I tell
> > it to do A, and it decides to do B, I will be extremely p'd off.
>
> I don't see what does that have to do with any of Alan's points.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

It ties a bit into the above, really. Concise, job specific tools that
do one thing and do them well, and don't try to magic up a guess of
what they think the user *wants* when it can't give what the user
*specifically* asked for are going to be a lot less destructive than
tools that *do* try to guess and go on their merry way (when they're
wrong) than simply handing the situation back to the user (not
necessarily the end user, just the user that asked for that tool, and
asked it to do that one job), who knows their particular
circumstances, as well as what they want in that instance.

I'll add in a very specific note that I'm not chiming in on the topic
of systemd itself, as I've yet to play with it anywhere. I'm just
chiming in on the "go on your merry way" part. The caller goes on
their merry way, not the called.

All that aside, your side of the discussions on systemd have, at
least, made me curious enough to throw together a vm to play with
sometime this week when I get time.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

24.02.2014 05:07, Alan McKinnon wrote:
[ ...]

> We don't do error handling. We don't even try and deal with it at the
> point it occurred, we just chuck it back up the stack, essentially
> giving them message "stuff it, I'm not dealing with this. You called me,
> you fix it."
>
> Doesn't sound like good design does it? Sounds more like do whatever you
> think you can get away with. Good design in this area gives you
> something conceptually along the lines of try...catch...finally (with
> possibly some work done to avoid throwing another exception in the
> finally).

try...catch...finally *does* leave error handling to *the caller*. It 
only provides a more object-oriented way to error handling. It *does 
not* *handle* errors.

> Unix error "design" does this:
>
> exit <some arb number>
> and an error message is in $@ if you feel like looking for it

Please, propose a more sound design? Take e.g. jQuery where all errors 
are handled by the library, it sometimes takes ages to debug why it 
doesn't work as expected, after a while you eagerly figure why error 
handling *should* be done by the caller, and the only thing the callee 
can do reliably is pass an error message upstream. Good error messages 
(and error codes, or error class hierarchy) are a different problem, but 
I haven't seen a more proof solution yet.

> Strangely, this approach is exactly why Unix took off and got such
> widespread adoption throughout the 70s. An engineer will understand that
> a well-thought out design that is theoretically correct requires an
> underlying design that is consistent. In the 70s, hardware consistency
> was a joke - every installation was different. Consistent error handling
> would severely limit the arches this new OS could run on. By taking a
> "Stuff it, you deal with it coz I'm not!" approach, the handling was
> fobbed off to a higher layer that was a) not really able to deal with it
> and b) at least in a position to try *something*.
>
> By ripping out the theoretical correctness aspects, devs were left with
> something that actually could compile and run. You had to bolt on your
> own fancy bits to make it reliable but eventually over time these things
> too stabilized into a consistent pattern (mostly by hardware vendors
> going bankrupt and their stuff leaving the playing field)
>
> And so we come to what "Unix design" probably really is:
>
> "You do what you have to to get the job done, the simpler the better,
> but I'm not *really* gonna hold you to that."

A good design is based on:
- consistency
- isolation and substitution of components
- component reuse
- thorough documentation
(a free interpretation of [1])

This almost always leads to many simple components, and that is what's 
called Unix design principles AFAIU.

The problem of Unix is that it doesn't follow "Unix design principles" 
any more. But it doesn't invalidate *the principles*.

> I still don't like what Lennart has done with this project, but I also
> fail to see what design principle he has violated.

As per [1], I fail to see what design principle he has followed.

[1] http://en.wikipedia.org/wiki/Software_design#Design_concepts

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

24.02.2014 02:32, Alan McKinnon wrote:
> On 23/02/2014 20:18, Canek Peláez Valdés wrote:
>> I don't think forking would attract much developers. Writing something
>> new trying to follow "the*nix design principles", but being modern and
>> with the same features (all of them optional, of course) of systemd
>> will have more chances; although I think it will fail because most of
>> the people that can code "better" actually like the systemd design,
>> and would prefer to contribute to it.
>>
>> And if you found enough of this mythical good-coders, good luck
>> defining what it means "the*nix design principles".
>
>
> I've been wondering about this concept of "the*nix design principles"...
>
> I've now concluded it's a myth, much like invisible pink unicorns.

I may not be an authority, too. But please allow me to refute your 
arguments.

> Is it like the kernel? A huge monolithic chunk of code with support for
> modules?

It ain't. No monolithic chunk of code, it's configurable.

> Is it like X11? A huge monolithic chunk of code that has a bizarre build
> system for years, and took something like 5 years of hard work to get it
> modular? And is 20 years behind the times? And *still* requires devs to
> jump through hoops to get a rendered image through a compositor and back
> up the the GPU?

It's grown to that, but in the beginning it was (striving to be) a clean 
system doing generally one thing (graphical client/server) and doing it 
well.
[1]
It's not X11 devs' fault that GPUs and all that multidisplay/ multimedia 
stuff don't work well with client/server arch because they were designed 
for some other, you know which, OS. I assume if the GPU vendors had 
their specs opened "20 years" ago, some wayland-like stuff would have 
been ready near that time.

> Is it like perl? Support every possible way to do something if it
> remotely makes sense to do it, no matter how bizarre the syntax?

Perl (I suppose you know what it stands for) is great (probably the 
greatest) for what it was invented for: text manipulation/analysis. It 
could have been a good replacement for many things like awk, sed, tr 
etc. if the author were less ambitious to conquer the world with Perl.

> Is it like python? Pick ONE way to do it and stick with it dammit!

You misquoted. The phrase is: "there should be one—and preferably only 
one—obvious way to do it", *one* meaning 'at least one', complemented 
with *should be* and *obvious*.

> Is it like php? Do whatever you feel like?

Php was a Unix design? LOL. Php wasn't a design at all. It was just 
another personal home pages perl script.

> Is it like command line text processing tools that only do one narrow
> thing well? [1]

Perfectly well.

> Is it like bash? I can't find a decent description of how bash came to
> be except it's like Vogons - wasn't designed and didn't evolve, it just
> sort of ... congealed

Bash or sh? What about ksh, csh, zsh etc? Well, a shell actually does 
two things: interactive shell and scripting. Let's ponder on how they 
can be separated?

> Not to rain on anyone's parade, but there's a prize of 40 internets up
> for the first person who can clearly and unambiguously define "Unix
> design principles" with specificity so that it is globally applicable.

A truism: There's nothing globally applicable.

> Best I can come up with is "Use common sense and build stuff that can be
> used and maintained" which is wonderfully descriptive but really sucks
> as a definition.

Something like this, but neither is it globally applicable.

>
>
> [1] For lack of a better term, let's just call systemd here a "system
> controller". What is this ONE thing a system controller should do and do
> it well?

An init daemon generally does one thing well.


[1] http://en.wikipedia.org/wiki/X11#Principles

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> 24.02.2014 02:32, Alan McKinnon wrote:
>> [1] For lack of a better term, let's just call systemd here a "system
>> controller". What is this ONE thing a system controller should do and do
>> it well?
>
>
> An init daemon generally does one thing well.

it's obvious you haven't thought this through.

consider, for a moment, that the "one thing well" that an init daemon
is supposed to do is
"run programs that do arbitrary things to get the system to an arbitrary state".

do you not see a problem?
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

24.02.2014 16:39, Mark David Dumlao пишет:
> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
>> 24.02.2014 02:32, Alan McKinnon wrote:
>>> [1] For lack of a better term, let's just call systemd here a "system
>>> controller". What is this ONE thing a system controller should do and do
>>> it well?
>>
>>
>> An init daemon generally does one thing well.
>
> it's obvious you haven't thought this through.
>
> consider, for a moment, that the "one thing well" that an init daemon
> is supposed to do is
> "run programs that do arbitrary things to get the system to an arbitrary state".
>
> do you not see a problem?

No. As you say, ``an init daemon is supposed to do is "run programs``, 
until here you're right, but then you start talking about things the 
init doesn't do but the programs do. In your wording, an init daemon is 
also a DBMS, an MTA, a network startup daemon, a firewall, a getty and 
whatever program runs on the system.
There was a post in this thread with a link to an opinion what an `ideal 
init` would do: just fork and exec anything in /etc/init.d or somewhere 
else.
In the real world, it's of course not so simple. But it doesn't mean you 
may imply init's responsibility for `arbitrary` tasks. If I write an ASM 
program with an illegal instruction, is it the init's problem? If my 
mail/web server is DDOSed, is it the init's problem? If my HDD dies, 
also the init's problem?

-- 
Regards,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
>
>
> 24.02.2014 16:39, Mark David Dumlao пишет:
>
>> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-uno@yandex.ru>
>> wrote:
>>>
>>> 24.02.2014 02:32, Alan McKinnon wrote:
>>>>
>>>> [1] For lack of a better term, let's just call systemd here a "system
>>>> controller". What is this ONE thing a system controller should do and do
>>>> it well?
>>>
>>>
>>>
>>> An init daemon generally does one thing well.
>>
>>
>> it's obvious you haven't thought this through.
>>
>> consider, for a moment, that the "one thing well" that an init daemon
>> is supposed to do is
>> "run programs that do arbitrary things to get the system to an arbitrary
>> state".
>>
>> do you not see a problem?
>
>
> No. As you say, ``an init daemon is supposed to do is "run programs``, until
> here you're right, but then you start talking about things the init doesn't
> do but the programs do. In your wording, an init daemon is also a DBMS, an
> MTA, a network startup daemon, a firewall, a getty and whatever program runs
> on the system.

Let's try to talk you through to a soft landing here.

When we say init, are we just referring to pid 1, or are we referring
to something
else entirely?

OpenRC is often spoken of in the same breath as systemd, as if they were
the same kind of thing. That sounds fair but think about it for a second:

openrc - as most people talk about it - isn't even pid 1. as most people
talk about it, openrc includes the functions.sh, the net.eth0 scripts,
the script
for starting your /sys, /proc, mounting local and network filesystems, setting
the hostname and so on.


They may be written in a different language from pid1, but when people
talk about
openrc, they are talking about that whole ball of wax. From a systems
perspective - they're parts of the same thing.

Even discounting the parts that you think are ridiculous, like databases and
loggers, there are clearly more parts in there above than can be cleanly defined
as "one thing".

Who gets to decide which is the "one thing" or not? You? Don't you rely on
openrc to set your hostname? Load your kernel modules? Run your sysctl?
Set any miscellaneous options in /sys? Mount your filesystems?

Go ahead, define for everyone, once and for all, what this "one thing" is.

Does this one thing init include  a subsystem for reading separate
environment files per-service? Isn't this just feature creep? Can't you just
edit the init scripts to add those in? I mean, they are already
scripts after all.
And they're in /etc, they're meant to be configured.

Does this one thing include service dependencies? Why sysv has gone for
a LONG time without them, just a sequencing, and that works fine for almost
all cases anyways. Isn't this just feature creep? Can't you just edit the init
scripts to start any dependent services?

Point is - go look at any arbitrary feature that's part of your "init
system" and
you could cry to hell and high water that it's violating the "one
thing", whatever
that "one thing" is that doesn't seem to be defined.

At least with systemd the parts are cleanly split off into separate executables.
Yes, it's technically not needed for pid 1 to create tempfiles for
other programs.
That's why systemd-tmpfiles is its own tiny program, that does one "one thing"
(create tempfiles for other programs) and nothing else. Yes, it's technically
not needed for pid 1 to check your filesystems. That's why systemd-fsck is
once again, a separate utility, that does "one thing" (run fsck) well. Yes,
it's technically not needed for pid 1 to remount your filesystems readwrite.
Again there's a separate utilty for that, that does nothing but just that.

It's clear to me that there's an analogue between the different parts of a
full openrc system - that just happen to be implemented in scripts - and
the different parts of a systemd system - that just happen to be implemented
in small binaries.

Every time people complain about systemd having too many features,
they just _casually_ forget to mention that, for instance, their init actually
asks them if they want to run interactive (why do that when you can specify
from the boot loader?) or checks the configuration files of their daemons
to see if they're valid and prompts the user to config if not. They just
_casually_ fail to mention that their init has plugins for NetworkManager
and ifplugd, that it comes with scripts for setting the consolefont.
Meanwhile systemd does those same things, and it's bloated, theirs
isn't.

Oh you're going to say that that's not fair, it's external optional stuff,
it's not _really_ part of openrc, but that's not intellectually honest is it?
Heck, I could do that same. I could control my bootup process so that
I run my own stuff instead of systemd-fsck, systemd-tmpfiles,
systemd-mount and all that jazz and run plain old init scripts in their
place.

Why bother?

The reality is that - init scripts don't do just one thing, and don't even
do it well.
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 24.02.2014 18:33, Mark David Dumlao wrote:
> On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
>>
>>
>> 24.02.2014 16:39, Mark David Dumlao пишет:
>>
>>> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff <yks-uno@yandex.ru>
>>> wrote:
>>>>
>>>> 24.02.2014 02:32, Alan McKinnon wrote:
>>>>>
>>>>> [1] For lack of a better term, let's just call systemd here a "system
>>>>> controller". What is this ONE thing a system controller should do and do
>>>>> it well?
>>>>
>>>>
>>>>
>>>> An init daemon generally does one thing well.
>>>
>>>
>>> it's obvious you haven't thought this through.
>>>
>>> consider, for a moment, that the "one thing well" that an init daemon
>>> is supposed to do is
>>> "run programs that do arbitrary things to get the system to an arbitrary
>>> state".
>>>
>>> do you not see a problem?
>>
>>
>> No. As you say, ``an init daemon is supposed to do is "run programs``, until
>> here you're right, but then you start talking about things the init doesn't
>> do but the programs do. In your wording, an init daemon is also a DBMS, an
>> MTA, a network startup daemon, a firewall, a getty and whatever program runs
>> on the system.
>
> Let's try to talk you through to a soft landing here.
>
> When we say init, are we just referring to pid 1, or are we referring
> to something
> else entirely?

Sorry but I think I was quite clear:
 >>>> An init daemon generally does one thing well.
Following a "Unix way" design, Everything else should be done by 
something else.

> OpenRC is often spoken of in the same breath as systemd, as if they were
> the same kind of thing. That sounds fair but think about it for a second:

Sorry but did I mention OpenRC?

> openrc - as most people talk about it - isn't even pid 1. as most people
> talk about it, openrc includes the functions.sh, the net.eth0 scripts,
> the script
> for starting your /sys, /proc, mounting local and network filesystems, setting
> the hostname and so on.

Obviously. That is why OpenRC *can* be treated as a "Unix way" thing, 
because the whole bunch are pretty interchangeable, independent and do 
their own things well, don't they?

> They may be written in a different language from pid1, but when people
> talk about
> openrc, they are talking about that whole ball of wax. From a systems
> perspective - they're parts of the same thing.
>
> Even discounting the parts that you think are ridiculous, like databases and
> loggers, there are clearly more parts in there above than can be cleanly defined
> as "one thing".
>
> Who gets to decide which is the "one thing" or not? You? Don't you rely on
> openrc to set your hostname? Load your kernel modules? Run your sysctl?
> Set any miscellaneous options in /sys? Mount your filesystems?
>
> Go ahead, define for everyone, once and for all, what this "one thing" is.
 >
> Does this one thing init include  a subsystem for reading separate
> environment files per-service? Isn't this just feature creep? Can't you just
> edit the init scripts to add those in? I mean, they are already
> scripts after all.
> And they're in /etc, they're meant to be configured.

Sorry, do you mean *everything* in /etc/ is to be configured? That's a 
convention to put the init stuff in /etc/. You could as well put it in 
/usr, /boot, wherever. In FreeBSD, the local init stuff resides in 
/usr/local/etc. In Solaris, elsewhere. In AIX, elsewhere. Why do you 
look at everything from a single linux's angle? Please note, I never say 
the 'linux way' but the "Unix way".
And you might also notice, an init system does not really much depend on 
the init daemon. It's pretty possible to run a SysV init daemon on a BSD 
system, or the opposite, because all the init daemon does is start some 
init scripts. Maybe /etc/rc, maybe /etc/init.d/* ...

> Does this one thing include service dependencies?

This depends on what one thing you want the init daemon to do. In e.g. 
FreeBSD, the dependencies are handled by /etc/rc.

 > Why sysv has gone for
> a LONG time without them, just a sequencing, and that works fine for almost
> all cases anyways. Isn't this just feature creep? Can't you just edit the init
> scripts to start any dependent services?
 >
> Point is - go look at any arbitrary feature that's part of your "init
> system" and
> you could cry to hell and high water that it's violating the "one
> thing", whatever
> that "one thing" is that doesn't seem to be defined.
>
> At least with systemd the parts are cleanly split off into separate executables.
> Yes, it's technically not needed for pid 1 to create tempfiles for
> other programs.
> That's why systemd-tmpfiles is its own tiny program, that does one "one thing"
> (create tempfiles for other programs) and nothing else. Yes, it's technically
> not needed for pid 1 to check your filesystems. That's why systemd-fsck is
> once again, a separate utility, that does "one thing" (run fsck) well. Yes,
> it's technically not needed for pid 1 to remount your filesystems readwrite.
> Again there's a separate utilty for that, that does nothing but just that.

Okay, but can I take them out and substitute mine own easily? How? Is 
there a well-defined standard? Is there a well-defined objective, a 
target at which the systemd software set will be considered stable 
'version 1.0'? I am asking again, if a bug is found in the systemd 
infrastructure, is it possible (i.e. how much effort it would take) to 
fix it temporarily on a running system?

> It's clear to me that there's an analogue between the different parts of a
> full openrc system - that just happen to be implemented in scripts - and
> the different parts of a systemd system - that just happen to be implemented
> in small binaries.
>
> Every time people complain about systemd having too many features,

I don't. Quite the opposite, I say, OpenRC has marginally less (if ever) 
features than systemd. Mentioned cgroups? The Wikipedia article about 
OpenRC states that it supports cgroups. Mentioned parallel startup? 
OpenRC supports it. Talked about `tail'ing last N log lines? I am quite 
sure that it would be a matter of minutes to get OpenRC to support this 
(assuming logs properly set up). And so on.

> they just _casually_ forget to mention that, for instance, their init actually
> asks them if they want to run interactive (why do that when you can specify
> from the boot loader?) or checks the configuration files of their daemons
> to see if they're valid and prompts the user to config if not. They just
> _casually_ fail to mention that their init has plugins for NetworkManager
> and ifplugd, that it comes with scripts for setting the consolefont.
> Meanwhile systemd does those same things, and it's bloated, theirs
> isn't.

I heard about 'the bloated stuff', too. I don't generally agree with it. 
But from what I see I conclude that systemd is bloating. It devours the 
environment, leaving the system with a set of tightly interconnected, 
hardly logical (IMO) but ultimately ambitious tools which are developing 
with priority of their number to their stability. The target feature set 
is not well-defined, and never will, as seen from the past issues - a 
permanent blatant feature creep.

> Oh you're going to say that that's not fair, it's external optional stuff,
> it's not _really_ part of openrc, but that's not intellectually honest is it?
> Heck, I could do that same. I could control my bootup process so that
> I run my own stuff instead of systemd-fsck, systemd-tmpfiles,
> systemd-mount and all that jazz and run plain old init scripts in their
> place.

No, really. What does systemd *add* what is missing and impossible to do 
with OpenRC?

> Why bother?

That's what I say. Why bother, if OpenRC already has almost everything 
you need. And what it doesn't, probably could be added with much less 
mess of writing a whole init system from the ground up and with much 
less transition cost and with much less hype about how cool the 
developers are to reinvent a Brand New Wheel. Could you advertise 
yourself more if you were just amending a SysV init system?
(Hell, and who did say that we are ranting here instead of writing code; 
what could have been SysV init like if those guys had written code for 
it? -- Ah no, it's probably even better that they didn't.)

> The reality is that - init scripts don't do just one thing, and don't even
> do it well.

The init scripts altogether don't do one thing, and I never said this. A 
single init script usually does. Why not always quite well? Because it 
depends not only on the script, but on the software itself. Do you claim 
a systemd unit file does the thing better than a shell script? No it 
just can't, I see many (if not most) of the unit files just issue commands.
The problem of the current SysV init system is that during its history 
there was a great number of different people writing different scripts 
in different styles as per their understanding of 'well'. But these 
could easily be conducted to a standard, actually e.g. FreeBSD has no 
problem with init scripts. Neither do I think OpenRC does.

In fact, by chance I'm here a 'sacrifice' because many things you (and 
other posters) attributed to me I either didn't say at all or said quite 
differently. ('Bloated systemd' is one example; comparing the whole 
systemd infrastructure to a single init daemon is another, etc.)

I didn't want to throw off systemd as a choice of a solution. (Yet I 
don't consider it *the* solution.) I was talking more about its 
unjustified hype and ambitions and indeterminate goals. While I do have 
some technical expertise, I surely don't have it enough to judge the 
design impartially. (Please respond anyone who claims he has.) And to be 
fair, I mostly didn't criticize the technical aspects of systemd about 
which I really care far less than about the `policy to conquer the world`.

I do respect the PoV of systemd's supporters as long as it solves their 
problems, but I personally don't have problems that only systemd could 
solve. My personal experience with it (though back in OpenSUSE 12.2-3), 
the opinions of my mates and the stuff I'm reading have already formed 
my point of view which says, systemd's claims are much of a soap bubble.

Well, at this point I'd rather really get back to my coding. Thanks 
everyone who bothered reading and answering.

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Tue, Feb 25, 2014 at 1:42 AM, Yuri K. Shatroff <yks-uno@yandex.ru> wrote:
> On 24.02.2014 18:33, Mark David Dumlao wrote:
> Sorry but I think I was quite clear:
>
>>>>> An init daemon generally does one thing well.
> Following a "Unix way" design, Everything else should be done by something
> else.
...
>> At least with systemd the parts are cleanly split off into separate
>> executables.
>> Yes, it's technically not needed for pid 1 to create tempfiles for
>> other programs.
>> That's why systemd-tmpfiles is its own tiny program, that does one "one
>> thing"
>> (create tempfiles for other programs) and nothing else. Yes, it's
>> technically
>> not needed for pid 1 to check your filesystems. That's why systemd-fsck is
>> once again, a separate utility, that does "one thing" (run fsck) well.
>> Yes,
>> it's technically not needed for pid 1 to remount your filesystems
>> readwrite.
>> Again there's a separate utilty for that, that does nothing but just that.
>
>
> Okay, but can I take them out and substitute mine own easily? How? Is there
> a well-defined standard? Is there a well-defined objective, a target at
> which the systemd software set will be considered stable 'version 1.0'? I am
> asking again, if a bug is found in the systemd infrastructure, is it
> possible (i.e. how much effort it would take) to fix it temporarily on a
> running system?
>

It's almost as if you don't bother reading the docs on something, then
comment that they're impossible.

Yes you can take them out and substitute yours, in fact I just
mentioned that I could replace them with plain old init scripts.
systemd services are controlled by the same unit files that control
other services.


>> OpenRC is often spoken of in the same breath as systemd, as if they were
>> the same kind of thing. That sounds fair but think about it for a second:
>
>
> Sorry but did I mention OpenRC?
>

There is a context to this conversation that you appear to be selectively
ignoring, wherein openrc, sysvinit, and systemd are being compared, and
only one of them is being demonized as anti-Unix. I compared systemd above
_both_ to openrc and to sysvinit. The point being ethat systemd is not
comparable to _just_ init, but to the whole init ball of wax.

>
>> openrc - as most people talk about it - isn't even pid 1. as most people
>> talk about it, openrc includes the functions.sh, the net.eth0 scripts,
>> the script
>> for starting your /sys, /proc, mounting local and network filesystems,
>> setting
>> the hostname and so on.
>
>
> Obviously. That is why OpenRC *can* be treated as a "Unix way" thing,
> because the whole bunch are pretty interchangeable, independent and do their
> own things well, don't they?
>

interchangeable:
I also pointed out that the systemd parts, like openrc parts, are
interchangeable, and do their own things well. I did mention, for example,
that I could replace systemd-fsck with an init script. Heck I could disable
it entirely if I didn't care about fsck (for instance, in a container). Likewise
the mount unit the network units, etc etc can be disabled or replaced
if wanted.

independent:
I do not think independent is an important concept for Unixness, as most of
the parts of postfix, dovecot, xorg, qmail, squid, etc are not independent.


What you DIDN'T and have not been able to point out is what this one thing
that pid 1 is supposed to do.

What you also have not been able to demonstrate is that openrc or other
init systems' parts follow the same criteria. There's was a long-standing bug,
for instance, in that functions.sh has not been separated from openrc.
I believe Canek was one of the people pushing to have it done so - to
better support systemd - something that violates "independence" and
"interchangeability".


> Sorry, do you mean *everything* in /etc/ is to be configured? That's a
> convention to put the init stuff in /etc/. You could as well put it in /usr,
> /boot, wherever. In FreeBSD, the local init stuff resides in /usr/local/etc.
> In Solaris, elsewhere. In AIX, elsewhere. Why do you look at everything from
> a single linux's angle? Please note, I never say the 'linux way' but the
> "Unix way".

/etc scripts ARE meant to be configured. At the very minimum, from the
perspective of gentoo, they are treated by the conf-update tool as config files.
You are expected to copy and customize init scripts for custom or local
daemons.

> And you might also notice, an init system does not really much depend on the
> init daemon. It's pretty possible to run a SysV init daemon on a BSD system,
> or the opposite, because all the init daemon does is start some init
> scripts. Maybe /etc/rc, maybe /etc/init.d/* ...

This is besides the point. Different programs are free to rely on different
standards and different features. That openrc can't work or depend on
systemd is not systemd's fault, in the same way that not all parts of
postfix can work or depend on all parts of qmail.

None of this says anything about the unixiness of postfix or qmail, none
of this says anything about the unixiness of init or systemd.


> No, really. What does systemd *add* what is missing and impossible to do
> with OpenRC?
>

That's really besides the point to me. This issue is supposed to be whether
systemd is unix-like or not. 1, you haven't shown how the traditional init
follows even your own notions of unixness. 2, you haven't show how systemd
fails to follow the same notions of unixness as the traditional init.

If you're really looking for one, I pointed out two earlier in this
thread. systemd
reliably stops services (openrc and sysvinit simply silently fail) and
allows you
to debug the exact command line in seconds (glance at the unit file) as opposed
to minutes (parse the init script).

> The init scripts altogether don't do one thing, and I never said this. A
> single init script usually does.

No seriously, a lot of init scripts - even individually - do not do one thing,
nor do they do it well.

> Why not always quite well? Because it
> depends not only on the script, but on the software itself. Do you claim a
> systemd unit file does the thing better than a shell script? No it just
> can't, I see many (if not most) of the unit files just issue commands.
> The problem of the current SysV init system is that during its history there
> was a great number of different people writing different scripts in
> different styles as per their understanding of 'well'. But these could
> easily be conducted to a standard, actually e.g. FreeBSD has no problem with
> init scripts. Neither do I think OpenRC does.

init scripts fail because
1) they don't do just one thing.
for example, they try to create temp files and directories, and don't properly
exit / fail when those conditions are broken. there is a common sysad
problem where if you accidentally start a service as root you bork any
chances of the script starting it. that's acceptable, ok.
but worse than that, many init scripts _silently_ fail, because creating
files and directories with the right permissions is not really its "one thing".

2) they don't properly track process ids, because they rely on pid files rather
than tracking all spawned / forked processes.
It seems to me that - barring kernel hints - tracking all spawned and forked
processes is the job of the process that spawned them and something
that it would be in a position to inform the scripts of. in systemd I think
pid1 does the spawning, so naturally pid1 does the tracking. It just so
happens that it does so using cgroups.

So yes, as of right now, in the real world, unit files are better than
init scripts,
EVEN IF they issue the same commands, simply for breaking and terminating
more reliably.

> In fact, by chance I'm here a 'sacrifice' because many things you (and other
> posters) attributed to me I either didn't say at all or said quite
> differently. ('Bloated systemd' is one example; comparing the whole systemd
> infrastructure to a single init daemon is another, etc.)
>

I didn't attribute anything to you you didn't say. It just so happens, though
that there is a context to this conversation, which, if you ignore, just
tends to perpetuate a lot of confusion. I am responding to questions and
points in that context for the benefit of the larger conversation, not
just for you.

-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Yuri K. Shatroff]

On 24.02.2014 22:55, Mark David Dumlao wrote:
[...]
>
> I didn't attribute anything to you you didn't say. It just so happens, though
> that there is a context to this conversation, which, if you ignore, just
> tends to perpetuate a lot of confusion. I am responding to questions and
> points in that context for the benefit of the larger conversation, not
> just for you.

I'll be short.

You also ignored much of what I asked, and tend to answer "that's 
besides the point" to things which IMO matter.
If you are responding to my post, then I'm expecting you to be replying 
to me, rather than to the benefit of the larger conversation, if you 
didn't say otherwise. ;-)
As for the context, I was answering to Alan's ``I've been wondering 
about this concept of "the*nix design principles"... `` which (as well 
as my answer) didn't mention systemd and openrc at all.
In this thread, there's already a rattling mixture of contexts. I'm 
opting out of it, because I no longer see the benefit of the larger 
conversation here.
Nevertheless, thank you for your time and answers.

-- 
Best wishes,
Yuri K. Shatroff

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 5805 bytes --]

On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote:
> On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@gmail.com> wrote:
> 
> [ snip ]
> 
> > Well, I'm no authority on this since I can't code,
> 
> My point exactly.

I think your point is not valid, unless you view Linux as an operating system 
intended for and inviting comments only from an inspired l33t who can code and 
it is *only* their user requirements that count.

I understand though that it is their/their employer's choice as to how they 
spend their coding time and what they spend it on.  I am not ungrateful for 
their generosity whether I agree with their approach or not.


> And that's the point; the people doing this changes *obviously
> understand Unix*. They understand it so well that they are able to
> look at it honestly, beyond dogma or articles of faith, and see its
> downsides, so they can try to fix them.

You seem to have a lot of faith in their approach and choice-limiting 
decisions.  They have made arbitrary decisions in developing their software in 
ways contrary to their predecessors.  I don't know if this is because they are 
cleverer than their predecessors, or more ignorant/arrogant/wrong.


> >   http://en.wikipedia.org/wiki/Unix_philosophy
> 
> This reminds me of the people that quote from religious books to argue
> about anything non theological. The "rules" and "sound bites" in the
> links you provide are there to summarize rules of thumb; they are NOT
> scripture, and they are certainly NOT the only way to get a
> technically good program that is easily maintainable. In other words,
> you can ignore most of them, or just following them to a point, and
> anyway end up with a sound design and a technically great program that
> is easy to maintain and extend.

I agree.  This is not a religion, but a statement of design principles based 
on some observations of what seemed to work (at the time) that were made after 
the event.


> The people with coding experience (or most of them anyway) understand
> this; we are not a religion, we don't have prophets that speak the
> undeniably truth. We have highly skilled developers who can have
> opposing views on how to design and implement many different ideas,
> and that doesn't (necessarily) means that any of them are wrong.

We agree again, except that some of these opposing ideas are limiting future 
development choices and current user options.


> There are many ways to solve a problem of sets of problems. Having
> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is
> "wrong", nor the other way around.

KDE took a wrong turn the moment it started emulating Gnome by hardcoding 
redland a whole host of components in its pursuit of a semantic desktop, 
removing choice from users who would be otherwise very happy with the KDE3 
functionality.  Many users have voted with their feet - not because they can 
code better or code at all, but because they still have a choice as plain 
users.

At least KDE has not hardcoded a requirement for systemd as Gnome now has.


> >> I've now concluded it's a myth, much like invisible pink unicorns.
> >> 
> >> Is it like the kernel? A huge monolithic chunk of code with support for
> >> modules?
> > 
> > I would think that although the kernel has grown over the years, it has
> > not done so like systemd.  You can still *not* build modules you don't
> > need in your kernel.
> 
> This has nothing to do with "Unix principles"; it's just that someone
> willing and able implemented the different options.

Well, "someone willing and able implemented the different options", but did so 
by following the paradigm of modular development.


> > The Unix design philosophy may not be globally applicable, but has served
> > Linux well over the years.
> 
> No; what has served Linux is to have developers willing and able to
> write the necessary code, following whatever design they decide is the
> correct one.

I think we have a fundamental disagreement here.  The Unix design principles 
inc. modularisation and extensibility make good sense when seen from the 
perspective of many contributors adding to and improving code in a piece meal 
fashion.  X11 did not follow this approach and ended up with convoluted 
unmaintainable code that had to be broken up.

Having developers able and willing to write code is of course a precondition, 
but not just any code.  It has to be code which others can pick up, improve 
and extend.  In other words, they have to write code which is versatile, being 
respectful of and keeping in mind future development effort.


> > Lennart has de facto introduced a different way of
> > developing his Linux code, which to others and me seems more restrictive.
> 
> First of all, it's not only Lennart; the systemd repo has (literally)
> dozens of contributors with write access.
> 
> Second of all, calling "restrictive" the tightly integrated approach,
> is exactly as constructive as calling "anarchic" the loosely
> integrated one. Like "Unix principles", it means nothing and it says
> nothing.

On the contrary, I think it says something quite specific:  Lennart and other 
contributors have  decided to not follow a modular approach and have hard 
wired components into a growing monolith.  In doing so they have remove choice 
from users.  You want Gnome?  You *must* user systemd.  At least for this 
reason alone his and other contributors design approach is deficient and 
criticised by many as inappropriate for Linux.

I expect that ultimately, this hard wiring will meet its timely end because it 
is by its nature self-limiting and a new development effort will start again.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Mon, Feb 24, 2014 at 2:54 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote:
>> On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@gmail.com> wrote:
>>
>> [ snip ]
>>
>> > Well, I'm no authority on this since I can't code,
>>
>> My point exactly.
>
> I think your point is not valid, unless you view Linux as an operating system
> intended for and inviting comments only from an inspired l33t who can code and
> it is *only* their user requirements that count.

Of course comments can come from anyone. But it stands to reason that,
in the first place, the people *writing* the code would primarily
listen to people that actually know what they are talking about. In
the second place, even if they *listen*, that doesn't mean they will
*implement* whatever a random set of users ask for.

> I understand though that it is their/their employer's choice as to how they
> spend their coding time and what they spend it on.  I am not ungrateful for
> their generosity whether I agree with their approach or not.

Glad to hear that.

>> And that's the point; the people doing this changes *obviously
>> understand Unix*. They understand it so well that they are able to
>> look at it honestly, beyond dogma or articles of faith, and see its
>> downsides, so they can try to fix them.
>
> You seem to have a lot of faith in their approach and choice-limiting
> decisions.

I have nothing even remotely close to "faith". I can read code, I can
read design documents, and I follow the discussions in the different
forums where systemd is the topic. It's my educated and reasonable
conclusion that their approach is correct (in general terms; of course
I don't agree with everything).

> They have made arbitrary decisions in developing their software in
> ways contrary to their predecessors.

Excuse me, but where do you get the idea to call their decisions
"arbitrary". Again, read the code (if you are able to), read the
design documents, read the discussions. You can disagree with their
decisions (I do with some of them); but I don't think there is a
single one that can be called "arbitrary".

>  I don't know if this is because they are
> cleverer than their predecessors, or more ignorant/arrogant/wrong.

Not necessarily "cleverer"; they just have more software history
available to determine what it works and what it doesn't.

>> >   http://en.wikipedia.org/wiki/Unix_philosophy
>>
>> This reminds me of the people that quote from religious books to argue
>> about anything non theological. The "rules" and "sound bites" in the
>> links you provide are there to summarize rules of thumb; they are NOT
>> scripture, and they are certainly NOT the only way to get a
>> technically good program that is easily maintainable. In other words,
>> you can ignore most of them, or just following them to a point, and
>> anyway end up with a sound design and a technically great program that
>> is easy to maintain and extend.
>
> I agree.

Glad to hear that.

> This is not a religion, but a statement of design principles based
> on some observations of what seemed to work (at the time) that were made after
> the event.

You said it: "at the time". Hardware is highly dynamic now; hard
drives, sound cards, network cards, memory and even CPUs can come and
go while the systems is running. SysV (and therefore, OpenRC) was
*never* intended to work like that, so what it does it does badly, if
at all.

>> The people with coding experience (or most of them anyway) understand
>> this; we are not a religion, we don't have prophets that speak the
>> undeniably truth. We have highly skilled developers who can have
>> opposing views on how to design and implement many different ideas,
>> and that doesn't (necessarily) means that any of them are wrong.
>
> We agree again, except that some of these opposing ideas are limiting future
> development choices and current user options.

No they are not; THE CODE IS OUT THERE. Anyone can take the code at
any point in time before systemd, and start a new path if this one
turns out to be failing. There is no "limiting" no one and nothing;
while there are people willing and able to, any design path can be
explored.

>> There are many ways to solve a problem of sets of problems. Having
>> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is
>> "wrong", nor the other way around.
>
> KDE took a wrong turn the moment it started emulating Gnome by hardcoding
> redland a whole host of components in its pursuit of a semantic desktop,
> removing choice from users who would be otherwise very happy with the KDE3
> functionality.  Many users have voted with their feet - not because they can
> code better or code at all, but because they still have a choice as plain
> users.

That's your analysis; I really don't like KDE, but I love my GNOME 3
desktop. That's subjective and has nothing to do with the topic at
hand; I was talking about how different (and sometimes opposite) ways
to solve a problem doesn't mean (necessarily) that one of them is
wrong.

> At least KDE has not hardcoded a requirement for systemd as Gnome now has.

GNOME has no hardcoded requirement for systemd; do your homework.

>> >> I've now concluded it's a myth, much like invisible pink unicorns.
>> >>
>> >> Is it like the kernel? A huge monolithic chunk of code with support for
>> >> modules?
>> >
>> > I would think that although the kernel has grown over the years, it has
>> > not done so like systemd.  You can still *not* build modules you don't
>> > need in your kernel.
>>
>> This has nothing to do with "Unix principles"; it's just that someone
>> willing and able implemented the different options.
>
> Well, "someone willing and able implemented the different options", but did so
> by following the paradigm of modular development.

Not true; not always anyway. And that's my point; if the "rule" is
only applied sometimes THERE IS NO RULE.

>> > The Unix design philosophy may not be globally applicable, but has served
>> > Linux well over the years.
>>
>> No; what has served Linux is to have developers willing and able to
>> write the necessary code, following whatever design they decide is the
>> correct one.
>
> I think we have a fundamental disagreement here.  The Unix design principles
> inc. modularisation and extensibility make good sense when seen from the
> perspective of many contributors adding to and improving code in a piece meal
> fashion.

In some cases, yes, they did. In others (like systemd), they didn't;
do your homework and study that cases. Just like systemd

Why? Because this is not a religion, and there is no hard rule. There
are rules of thumb that you can ignore if you think your design works
better without them.

Like systemd (in general).

> X11 did not follow this approach and ended up with convoluted
> unmaintainable code that had to be broken up.

And the declared crap by the same X11 developers, and now they are
focusing in Wayland.

> Having developers able and willing to write code is of course a precondition,
> but not just any code.  It has to be code which others can pick up, improve
> and extend.

I agree; that's why systemd has recruited dozens of developers from
basically all distributions under the sun, and they are able to pick
up, improve and extend the code. Like networkd; that's new. Or like
watchdog support. Or like SMACK labels. You name it.

>  In other words, they have to write code which is versatile, being
> respectful of and keeping in mind future development effort.

And that's the case of systemd's code, which if you took the effort to
learn how to program, you will be able to see by yourself. Even if it
doesn't follow all the "unix principles" to the rule, it is versatile
and keeping in mind future development effort. That's why GNOME, KDE
and Xfce would depend (optionally) on it; that's why the author of NFS
was happy to finally create a set of unit files that would work on any
distro; that's why embedded guys like Tizen or Jolla are using it.

>> > Lennart has de facto introduced a different way of
>> > developing his Linux code, which to others and me seems more restrictive.
>>
>> First of all, it's not only Lennart; the systemd repo has (literally)
>> dozens of contributors with write access.
>>
>> Second of all, calling "restrictive" the tightly integrated approach,
>> is exactly as constructive as calling "anarchic" the loosely
>> integrated one. Like "Unix principles", it means nothing and it says
>> nothing.
>
> On the contrary, I think it says something quite specific:  Lennart and other
> contributors have  decided to not follow a modular approach and have hard
> wired components into a growing monolith.

It's modular enough, where it has reasons to be.

>  In doing so they have remove choice from users.

Why? You can keep using the same stuff as before.

> You want Gnome?  You *must* user systemd.

This is simply not true; GNOME 3.10 *runs in OpenBSD*  [1]. Do. Your. Homework.

In Gentoo you need systemd, but that's a decision from the Gentoo
maintainers. They do the job, they make the choices.

> At least for this
> reason alone his and other contributors design approach is deficient and
> criticised by many as inappropriate for Linux.

Do your homework before saying things that are not true.

> I expect that ultimately, this hard wiring will meet its timely end because it
> is by its nature self-limiting and a new development effort will start again.

Wanna bet a beer that doesn't happen in the next 20 years? I'll bet a beer.

(I don't drink beer).

Regards.

[1] http://undeadly.org/cgi?action=article&sid=20140219085851
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 378 bytes --]

On Monday 24 Feb 2014 21:48:39 Canek Peláez Valdés wrote:

> > At least KDE has not hardcoded a requirement for systemd as Gnome now
> > has.
> 
> GNOME has no hardcoded requirement for systemd; do your homework.

I beg your pardon, I got this wrong - I extrapolated from the Gentoo state of 
affairs (I don't use or follow the Gnome project).

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 20/02/14, Canek Peláez Valdés wrote:

> > Thinking about this more, since apparently using a separate profile may
>    just
> > be 'overkill', how about something simpler, like, for example, using
> > eselect...
> >
> > Something like:
> >
> > # eselect init list
> > Available init systems:
> > [1] OpenRC *
> > [2] systemd
> > [3] runit
> >
> > (whatever choices are supported).
> >
> > Or am I just being ridiculous?

The eselect command is already there in Sabayon.

>    No, yo are not; but the switching requires reemerging things because you
>    need to set some USE flags and quit others. That's the "difficult" (which
>    is not, really) part; if you set the USE flags yourself or via a profile,
>    or an eselect module, I don't think the difference matters at all.

... but I have no idea how it is done. That's why I asked what packages
would require a reinstall (got no precise answer for now).

-- 
Nicolas Sebrecht

Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 2014-02-24 4:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> In Gentoo you need systemd, but that's a decision from the Gentoo
> maintainers. They do the job, they make the choices.

Interesting. Now I have to spin off a new thread as to why this decision 
was made if it isn't forced by GNOME itself...

Re: Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 25/02/2014 14:40, Tanstaafl wrote:
> On 2014-02-24 4:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> In Gentoo you need systemd, but that's a decision from the Gentoo
>> maintainers. They do the job, they make the choices.
> 
> Interesting. Now I have to spin off a new thread as to why this decision
> was made if it isn't forced by GNOME itself...
> 
> 
> 

Gnome uses logind, Canek has consistently stated that for months now.

logind is part of systemd (AIUI it's more "bundled" than "a chunk of a
monolothic lump") and replaces consolekit.

The feature set of logind can be implemented in something else. Or, that
functionality in previous Gnome versions forward-ported to 3.10 to be
able to drop logind as a dep.

OpenBSD would have had little choice in this as systemd doesn't run on
OpenBSD - systemd uses many features unique to the Linux kernel. So they
would have had to do *something* about logind. Whatever they did, it
would have been a non-trivial amount of work.

I suspect the Gentoo Gnome maintainers were not prepared to, or don't
have the manpower, to do the same on Gentoo so took the easier route of
depending on systemd.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: Gentoo+Gnome requires systemd, but Gnome itself does not? Why? - WAS: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 25, 2014 at 6:58 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 25/02/2014 14:40, Tanstaafl wrote:
>> On 2014-02-24 4:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> In Gentoo you need systemd, but that's a decision from the Gentoo
>>> maintainers. They do the job, they make the choices.
>>
>> Interesting. Now I have to spin off a new thread as to why this decision
>> was made if it isn't forced by GNOME itself...
>
> Gnome uses logind, Canek has consistently stated that for months now.

That is true; but no one have to trust me on anything. The code is out
there ([1], [2]); anyone can go and check what dependencies GNOME
exactly require.

> logind is part of systemd (AIUI it's more "bundled" than "a chunk of a
> monolothic lump") and replaces consolekit.

I'm not so sure about this anymore. It seems that logind actually uses
many of systemd features, and therefore is really difficult to
implement independently of it. For a high overview discussion of this,
you can check [3], where Ryan Lortie says:

"""
Some interfaces provided by systemd are less awesome. Even at the
D-Bus level, the interface for PID 1 or logind are so complicated and
implementation-specific that they could never be reasonably
independently implemented. These interfaces often mix multiple
functionality sets into one: for the logind case, for example, only a
small subset of this is ever required by a desktop environment running
as a normal user. Many other calls on the same interface are only
called by other operating system components.
"""

Ubuntu has been (and supposedly, still is) interested in having a
non-systemd replacement; but AFAIK, they don't have it yet. For
systemd <= 204 the code of logind was more independent of systemd
features, so they just cut it from there; after 205 (when the new
slices thingies were added to deal with the future cgroups API from
the kernel), this is no longer possible, so they need to actually
write an API compatible replacement. This hasn't come to fruition (and
because of the above quote, this doesn't look easy).

Perhaps a compromise could be reached where the desktop-necessary
parts of logind are isolated in their own dbus API.

As with everything, however, somebody should do that job.

> The feature set of logind can be implemented in something else. Or, that
> functionality in previous Gnome versions forward-ported to 3.10 to be
> able to drop logind as a dep.

In this case, the "something else" is ConsoleKit, which (AFAIK) works
in the *BSD.

> OpenBSD would have had little choice in this as systemd doesn't run on
> OpenBSD - systemd uses many features unique to the Linux kernel. So they
> would have had to do *something* about logind. Whatever they did, it
> would have been a non-trivial amount of work.

I don't think so; the source code I linked says (literally):

if test x$enable_systemd = xyes; then
       [ snip ]
        session_tracking="systemd (with fallback to ConsoleKit)"
else
        session_tracking=ConsoleKit
fi

So, it could be that is actually "trivial".

The real problem is that most GNOME developers don't use the
ConsoleKit code paths anymore, so the burden of works goes to the
people that don't have systemd (*BSD).

> I suspect the Gentoo Gnome maintainers were not prepared to, or don't
> have the manpower, to do the same on Gentoo so took the easier route of
> depending on systemd.

Most of them don't use OpenRC anymore, so they could perhaps see that
the code emerges without errors, but they would not be able to
actually test it. They rather decided to support what they could test,
than to give the appearance of "choice" when no one is really
supporting the CK code paths.

(Also, it seems undeniable that logind works so much better than CK ever did).

Regards.

[1] https://git.gnome.org/browse/gdm/tree/configure.ac#n882
[2] https://git.gnome.org/browse/gnome-session/tree/configure.ac#n123
[3] http://blogs.gnome.org/desrt/2014/02/19/on-portability/
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Canek Peláez Valdés]

On Tue, Feb 25, 2014 at 4:03 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 20/02/14, Canek Peláez Valdés wrote:
>
>> > Thinking about this more, since apparently using a separate profile may
>>    just
>> > be 'overkill', how about something simpler, like, for example, using
>> > eselect...
>> >
>> > Something like:
>> >
>> > # eselect init list
>> > Available init systems:
>> > [1] OpenRC *
>> > [2] systemd
>> > [3] runit
>> >
>> > (whatever choices are supported).
>> >
>> > Or am I just being ridiculous?
>
> The eselect command is already there in Sabayon.
>
>>    No, yo are not; but the switching requires reemerging things because you
>>    need to set some USE flags and quit others. That's the "difficult" (which
>>    is not, really) part; if you set the USE flags yourself or via a profile,
>>    or an eselect module, I don't think the difference matters at all.
>
> ... but I have no idea how it is done. That's why I asked what packages
> would require a reinstall (got no precise answer for now).

Sabayon uses binary packages, isn't? Then eselect perhaps uninstalls
some packages and installs others?

I've no idea; I've never used Sabayon, although I'm interested in trying it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 26/02/14, Canek Peláez Valdés wrote:

> Sabayon uses binary packages, isn't? 

Yes.

>                                      Then eselect perhaps uninstalls
> some packages and installs others?

I don't know the code, sorry. Since I've already tried the
'eselect init' command, I'm pretty sure it doesn't install anything.

> I've no idea; I've never used Sabayon, although I'm interested in trying it.

BTW, I'm pretty sure Fabio (cc'ed) will be fine to explain how he
implemented the eselect init command and the whole magic behind it. ,-)

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Stefan G. Weichinger]

Am 21.02.2014 23:43, schrieb Canek Peláez Valdés:

>> And now with 209 there is a new systemd-networkd deamon that is started
>> by default even if not configured or used.
>>
>> http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTI
> 
> $ ./configure --help | grep networkd
>   --disable-networkd      disable networkd
> 
> It can be disabled.

I run systemd-210 here already and have nothing like networkd running.

I didn't disable it myself, maybe the devs (upstream or gentoo) did so
per default.

Regards, Stefan

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Walter Dnes]

On Mon, Feb 24, 2014 at 12:32:32AM +0200, Alan McKinnon wrote

> Is it like perl? Support every possible way to do something if it
> remotely makes sense to do it, no matter how bizarre the syntax?

  The (d)evolution of perl reminds me of what's happened to Firefox,
GNOME, and KDE.  To paraphrase the emacs joke, perl is a mediocre
operating system that lacks a lightweight text-manipulation utility.
WTF does every simple program try to become an OS?

* The original "Practical Extraction and Reporting Language" PERL has
  become a pseudo-OS.  Believe it or not, it was a lightweight practical
  text-parsing and report-generating utility back in the day.

* Netscape (under AOL) aimed at becoming a pseudo-OS on top of Windows.
  We know how that turned out.

* I'm old enough to remember the days of the "Phoenix" betas (later
  Firebird then Firefox).  A lean/mean fast web-browser.  Now it's
  turned into a bloated monstrosity, complete with relational database,
  that's being used as the basis for Firefox-OS phones.

* Google's Chrome/Chromium came from Chrome-OS, so it's not too
  surprising that it demands dbus and udev to build.

* I remember when KDE and GNOME were zippy on machines with 64 megs of
  RAM.  The sad part is that the GNOME desktop had more features then
  than it has now as it moves towards becoming GNOME-OS.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Stroller]

On Wed, 26 February 2014, at 8:29 pm, Walter Dnes <waltdnes@waltdnes.org> wrote:
> … 
> * Netscape (under AOL) aimed at becoming a pseudo-OS on top of Windows.
>  We know how that turned out.

You appear to be underestimating it - whilst the AOL suite was hated by many of those "forced to use it" (I guess in the late 90's or early 00's), it is / was so massively popular with grannies that it is still available today. 

Dial-up division is still AOL's most profitable division, earning them $500m per year,[1] and I would attribute the popularity of the AOL desktop suite to this.

I've seen this profitability attributed to "misinformed customers" who "don't know they no-longer need AOL now they have DSL", but having been told by a number of people that all they want out of their computer is their AOL, I find it had to agree with that characterisation.

AOL's desktop suite has certainly not been a failure for the company.

Stroller.




[1] http://www.technobuffalo.com/2013/02/18/aol-dial-up-profits/

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Samuli Suominen]

On 28/02/14 08:47, Stroller wrote:
> On Wed, 26 February 2014, at 8:29 pm, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> … 
>> * Netscape (under AOL) aimed at becoming a pseudo-OS on top of Windows.
>>  We know how that turned out.
> You appear to be underestimating it - whilst the AOL suite was hated by many of those "forced to use it" (I guess in the late 90's or early 00's), it is / was so massively popular with grannies that it is still available today. 
>
> Dial-up division is still AOL's most profitable division, earning them $500m per year,[1] and I would attribute the popularity of the AOL desktop suite to this.
>
> I've seen this profitability attributed to "misinformed customers" who "don't know they no-longer need AOL now they have DSL", but having been told by a number of people that all they want out of their computer is their AOL, I find it had to agree with that characterisation.
>
> AOL's desktop suite has certainly not been a failure for the company.
>
> Stroller.
>
>
>
>
> [1] http://www.technobuffalo.com/2013/02/18/aol-dial-up-profits/
>
>

This must be a US -only thing since I've never even heard of AOL
desktop/suite before, even while lived through the 90's and the bulletin
board times (as being a SysOp myself ;-)

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Stroller]

On Fri, 28 February 2014, at 8:05 am, Samuli Suominen <ssuominen@gentoo.org> wrote:
>>> … 
>>> * Netscape (under AOL) aimed at becoming a pseudo-OS on top of Windows.
>>> We know how that turned out.
>> You appear to be underestimating it - whilst the AOL suite was hated by many of those "forced to use it" (I guess in the late 90's or early 00's), it is / was so massively popular with grannies that it is still available today. 
>> 
>> ...
>> AOL's desktop suite has certainly not been a failure for the company.
> 
> This must be a US -only thing since I've never even heard of AOL
> desktop/suite before, even while lived through the 90's and the bulletin
> board times (as being a SysOp myself ;-)

I'm in the UK, myself.

The AOL software is browser, email, IM and ads, all wrapped up in a single Windows application. 

http://i.imgur.com/bUin2ki.png

I doubt there's anyone on this list who wouldn't find it obnoxious, but there are people who are really happy with it.

Stroller.
 

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 886 bytes --]

On Friday 28 Feb 2014 13:45:12 Stroller wrote:
> On Fri, 28 February 2014, at 8:05 am, Samuli Suominen <ssuominen@gentoo.org> 
wrote:

> > This must be a US -only thing since I've never even heard of AOL
> > desktop/suite before, even while lived through the 90's and the bulletin
> > board times (as being a SysOp myself ;-)
> 
> I'm in the UK, myself.
> 
> The AOL software is browser, email, IM and ads, all wrapped up in a single
> Windows application.
> 
> http://i.imgur.com/bUin2ki.png
> 
> I doubt there's anyone on this list who wouldn't find it obnoxious, but
> there are people who are really happy with it.

I think it also comes with its own (branded) antivirus, since most of its 
users couldn't be trusted to set up or keep up with updates on their PC.  I 
can't recall if it also turns on and runs MSWindows Updates too.  :-p

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]

On Mon, 17 Feb 2014 21:52:55 +0400
Andrew Savchenko <bircoph@gmail.com> wrote:

> On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
> > On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> > <volkerarmin@googlemail.com> wrote:
> > > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
> > >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
> > >> <volkerarmin@googlemail.com> wrote:
> > >> [ snip ]
> > >>> or it is an idiotic decision. Because features means complexity.
> > >> Yeah, like the kernel.
> > >>
> > >>> Complexity means bugs.
> > >> Bugs get reported, bugs get fixes. Life goes on.
> > 
> > You didn't answered this, did you?
> 
> Bugs are different. Bugs in the critical system components are
> critical to the whole system. If Libreoffice or browser
> segfaults, some data may be lost and inconvenience created, but the
> system will continue to run. If PID 1 segfaults — everything is
> lost, you have a kernel panic. That's why critical components should
> be as simple and clean as possible.

If it does, but does it? We have run it for ages without a segfault.

> SysVinit code size is about 10 000 lines of code, OpenRC contains
> about 13 000 lines, systemd — about 200 000 lines.

That is an unfair comparison, be fair and consider PID 1's code size.

> Even assuming systemd code is as mature as sysvinit or openrc (though
> I doubt this) you can calculate probabilities of segfaults yourself
> easily.

Practical statistics are more reliable than theoretical probabilities.

> > >> All of them are different tools providing one capability to
> > >> systemd as a whole. So systemd is a collection of tools, where
> > >> each one does one thing, and it does it well.
> > >>
> > >> By your definition, systemd perfectly follows "the unix way".
> > >>
> > >
> > > no, it isn't.
> > >
> > > How are those binaries talk to each other?
> > 
> > dbus, which is about to be integrated into the kernel with kdbus.
> 
> And this is a very, very bad idea. Looks like you don't know matter at
> all: to begin with kdbus protocol is NOT compatible dbus and special
> converter daemon will be needed to enable dbus to talk to kdbus.

That claims it to be a bad idea, but doesn't tell why; furthermore, no
technical reasoning as to why it is incompatible is given. Do you know?

> The whole kdbus technology is very questionable itself (and was
> forcefully pushed by RH devs), anyway it is possible to disable this
> stuff in kernel and guess what will be done on my systems.

Similar claims again, without any weight; that is subjective opinion.

> > > Looks broken. Broken by design. The worst form of broken.
> > 
> > By your opinion, not others.
> 
> That is not just an opinion. 

It is due to the lack of science and experience in your response.

> And all that science was ignored during systemd architecture process
> if there was any at all.

For it to be claimed as "ignored", you need to know about the process;
given that you don't even know its presence, such claim can't be made.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Tue, 18 Feb 2014 04:05:03 +0200
Gevisz <gevisz@gmail.com> wrote:

> How can you be sure if something is "large enough" if, as you say
> below, you do not care about probabilities?

Statistics.

> If you do not care (= do not now anything) about probabilities
> (and mathematics, in general), you just unable to understand
> that debugging a program with 200K lines of code take
> 
> 200000!/(10000!)^20
> 
> more time than debugging of 20 different programs with 10K lines of
> code. You can try to calculate that number yourself but I quite sure
> that if the latter can take, say, 20 days, the former can take
> millions of years.

Assuming PID 1 is 200K lines; however, it's a lot smaller than that.

> It is all the probability! Or, to be more precise, combinatorics.  

That's too precise; both of these are just a part of something bigger,
that big thing is called statistics, in theory you can hold yourself on
to probabilities, but in practice statistics will give you guarantees.

> Have you ever tried forex? If yes, you should have been warned
> that "no past performance guarantee the future one."
>
> And if you do not believe that (and do not care about probability
> and all the stuff like that), you should visit any of the forex forums
> where you will be suggested a magical money winning strategy that, in
> the past, behaved very well and earned 200 or even 500% a month.

Same could be said about the opposite; seeing it in one way you would
want to ditch statistics with this statement, seeing it the other way
you would want to accept statistics with the opposite statement. It
effectively makes the statement lose its meaning in this context; as
said, statistics and the acceptance thereof is far more practical.

If you consider a segfault in PID1 or the kernel to be the end of the
world like losing tons of money, unless you run a critical appliance,
then you could reconsider the stability of the rest of your system.

Because in the end, you've put all your money in PID1 / kernel; whereas
the full picture includes a lot more than that (eg. core libraries),
so, a good winning strategy is to spare money for the rest out there.

(Where "winning" means preventing your world from falling apart)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Tue, 18 Feb 2014 15:56:53 +0200
Gevisz <gevisz@gmail.com> wrote:

> No, by arguing that fixing bugs in a 200K line program is as easy as
> fixing a bug in 20 10K line programs. It is just not true, just the
> opposite. 

So, as systemd is modular per the biggest myth #6[1]; that means that,
PID 1 being something like a 10K line program, is easy to fix.

 [1] http://0pointer.de/blog/projects/the-biggest-myths.html

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3659 bytes --]

On Tue, 18 Feb 2014 21:06:33 +0400
Andrew Savchenko <bircoph@gmail.com> wrote:

> Real world code without mistakes and larger than "Hello, world!"
> exercises is not possible. Large systems must have error suppression
> and correction techniques, modular and replaceable design is one of
> them, KISS is another one. Systemd has none known to me.

systemd does have both, see myths #6 and #29 of the biggest myths.

 [1]: http://0pointer.de/blog/projects/the-biggest-myths.html

> This depends on what bug at what component occurred. Just imagine
> pid 1 segfault on medical life support equipment. With systemd going
> into embedded this is not just pure speculation, though, of course
> medical stuff should have extra safeguards. But any FT or at
> least HA setup is a combination of multiple layers. I do not want to
> allow badly broken core component on mine setups even if its faults
> may be compensated by other means.

That's assuming the target public of systemd is medical life support
equipment; however, that is certainly not the case which makes that an
irrelevant example in this context.

When talking about life critical support, you'll need to have proper
specification and checks to have a guarantee; we've seen the APL
language and Z notation early on in this field, as well as evolutions
from and beside that.

Most life critical systems are based on such things; throwing whatever
thing on such a system, like the first open-source project you can
find, is is not how such systems are made.

Faults, if they happen at all, being compensated imo suffices for non
life critical systems; if you want more, you know the languages,
notations, checking tools and other practices are out there to benefit
from. An init system and/or service manager based on life critical
support standards would definitely have my interest; however, I am
wondering if there's anyone that wants to spend his free time on that.

> Yet again, I respect ones right to use whatever one wants, but I ask
> to respect mine as well. That's why I propose a separate systemd
> profile for those willing to use it.

They are there, `find /usr/portage/profiles/ -name '*systemd*'`.

> > >> Sorry, but it's you who doesn't know the matter at hand: kdbus
> > >> was (and is) written by Greg Kroah-Hartman, Linus' right hand,
> > >> and who works for the Linux Foundation.
> > >
> > > Lol, he seems to start to use the arguments like "You even do not
> > > know my elder brother/acquaintance from the street nearby who can
> > > easily hit you down!"
> > 
> > If you don't think Greg's words have any weight in a Linux-related
> > technical discussion, then I'm afraid we will need to agree to
> > disagree on any technical subject.
> 
> You know, common sense should always override person's prestige.
> History knows many examples. Sir Isaac Newton enforced corpuscular
> point of view on the light's nature. And while he was genius in other
> physical aspects, he was mistaken here. Albert Einstein was rejective
> to probabilistic nature of quantum mechanics and even proposed an
> entangled particles paradox as an example of its "flawed" nature.
> Though as we know these days such systems exist and are quite well
> used in numerous experiments. My point is simple: do not blindly
> adhere to someone's words, even if this person has high authority.
> Common sense must prevail. Period.

+1

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Tue, 18 Feb 2014 14:09:42 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> I totally get XFCE *supporting* the use of logind, but why should it 
> ever support *only* logind? That would seem insane to me.

If it were a decision, and other decisions were possible without cost,
yes; however, this often happens as the result of a lack of manpower to
support multiple systems. Others aren't stopped from forking and/or
wrapping XFCE to (also) support other login facilities than logind;
well, under the assumption that they would limit their support...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Wed, 19 Feb 2014 10:19:43 +0000
thegeezer <thegeezer@thegeezer.net> wrote:

> the difficulty is that without knowing

It is as easy as following the commits upstream makes, which is a
short daily visit (or for less important followers, even weekly);
that's really not too much asked for if you forked logind.

It is even quite common practice and scriptable:

    git fetch ... ; git log ... ; git diff ...

In a similar way, I know Portage will get highlighting and a ^ indicator;
without that being announced until release, here's a copy paste (note
that what is above ^ would be colored in red, unwrapped to unbreak it):

dev-lang/perl:0

  (dev-lang/perl-5.18.2:0/5.18::gentoo, ebuild scheduled for merge) pulled in by
    =dev-lang/perl-5.18* required by (virtual/perl-IO-1.280.0:0/0::gentoo, ebuild scheduled for merge)
    ^              ^^^^^                                                                                                                                     

  (dev-lang/perl-5.16.3:0/5.16::gentoo, installed) pulled in by
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/IO-Socket-SSL-1.967.0:0/0::gentoo, installed)
                 ^^^^^^^^                                                                                                                   
    =dev-lang/perl-5.16* required by (virtual/perl-libnet-1.230.0:0/0::gentoo, installed)
    ^              ^^^^^                                                                                                                        
    (and 19 more with the same problems)

And of course, that's not the only change happening; dependency
resolution will become faster, some slot operator bug fixes happened
but caused regressions in released versions and thus more of such fixes 
will be done, some "no parents" messages during slot conflict output 
were nuked, ...

If I can type that as part of this mail, people could follow logind.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Feb 2014 19:46:42 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> eselect manages config options between different implementation of a
> thing. Usually by tweaking symlinks. Switching init OpenRC <-> SystemD
> involves resetting uSE flags and recompiling some fundamental stuff.
> That exercise is unlikely to ever go into eselect.

Well, running systemd now I can reboot into OpenRC; it just works.

> The devs on gentoo-dev already nuked the idea of a gentoo profile as
> such, it's not worth the effort and causes an explosion of profiles.

It's happening, `find /usr/portage/profiles/ -name '*systemd*'`; does
it have any consequences that are worth thinking through?

> Conceptually, it is rather similar to switching between nouveau and
> nvidia. That doesn't have eselect support[1] or profiles.

Well, running NVIDIA now I can reboot with a simple script[1] put
in /etc/local.d/nvidia.start (with execute permission); this works for
me on both OpenRC and systemd, I'd say it is easy to do. Perhaps it can
even be made more easy by rewriting the Xorg configuration to be device
aware and therefore not needing the steps shown in this script.

 [1]: https://gist.github.com/TomWij/a13abacfb74999c10957

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Wed, 26 Feb 2014 09:07:17 +0100
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> I don't know the code, sorry. Since I've already tried the
> 'eselect init' command, I'm pretty sure it doesn't install anything.

While you might be able to code it to do such thing, it probably
shouldn't; it's a tool for "select"ing from multiple runtime things,
that it would (un)install something as part of it would be odd, kind of
makes one remember the UNIX philosophy of doing one thing right.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Feb 2014 17:33:43 +0000
thegeezer <thegeezer@thegeezer.net> wrote:

> Personally i'm most likely to stay with openRC, because the switch is
> non-trivial and have no faith in the xinetd-style socket arbitrator.

It should be trivial, it is here.

> but would eselect be able to script the following:
> .. new kernel coptions

Most of which you have already; beyond that, it's some minor
functionality that doesn't stop the switch itself from working afaik.

Only needs to be done once, not every time.

> .. new grub2 command line

A new entry with init=/usr/lib/systemd/system suffices and doesn't need
to be switchable; unless you want one entry and switch at runtime,
alternatively it is possible to emerge sys-apps/systemd-sysv-utils, or
simply change the symlink of /sbin/init and similar files yourself.

> .. install dbus (use=-systemd) _then_ systemd

Only needs to be done once, not every time.

> .. would be nice to use an import for localed and hostnamed and
> timedated .. importing openrc services and runlevels to targets

Would be nice to have.

Only needs to be done once, not every time.

> .. pamd logind entires

Only needs to be done once, not every time.

> .. syslogd changes to accomodate systemd

Is this necessary? I don't remember doing this.

> .. setting systemd to log to syslog to make transitions smoother (as
> logs are lost on reboot by default)

If this were to be done, this could be done in the systemd package.

Out of all what is mentioned; you either need two GRUB entries or a
single symlink that eselect controls, other than that there's nothing
here to be made as part of eselect. Some of these things already are
made the way they are by default, other things can happen as part of
emerging a package; the other first install things are documented.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Fri, 21 Feb 2014 09:53:51 +0400
Andrew Savchenko <bircoph@gmail.com> wrote:

> Gnome required systemd without alternative. Coincidence? I don't
> believe in them. I trust probabilities and statistics.

Gnome doesn't have such requirement; alternatives are possible, it's
not coincidence. I trust actual words from those that were involved:

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts

> OpenRC is default in Gentoo now, and it is my best hope it will be.

Do you have a source that backs up this claim? It comes as part of
stage3, but a systemd stage3 is being worked on[1]; however, it has only
temporarily been in the @system set (due to functions.sh[2] which is now
split) and will soon be removed from it.

 [1]: https://bugs.gentoo.org/show_bug.cgi?id=482702
 [2]: https://bugs.gentoo.org/show_bug.cgi?id=373219

> Thus anyone willing to use something else should do an appropriate
> job.

It is actively being worked on from what can be seen.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Feb 2014 09:50:24 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> All myself and others have been insisting on is that systemd
> proponents be prevented from unilaterally creating some kind of
> dependenc[y][ies] whereby, through that backdoor, they create a
> situation where the *current* *default* init system must be switched.

It are the consumers that do, sometimes even the packagers; because some
neat future that fits them is provided by one implementation, they adopt
that and given limited manpower they expect other implementations to
follow. This is whilst stating "However, long term hopefully
gnome-session can die and such code in systemd." in the following blog
post by a GNOME foundation as well as GNOME release team member:

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

On Gentoo, we indeed prevent such dependencies where manpower allows
us; for example, to give an opposite example, we've even removed
sys-apps/openrc from several package dependencies to allow for its
removal. The same is actively guarded for sys-apps/systemd; but for
both, you'll be able to find an exception to it here or there.

The same is said by one of the Gentoo Council members in a comment on
another blog post here, worth reading:

https://blogs.gnome.org/ovitters/2014/02/03/my-thoughts-on-the-default-init-system-for-debian-discussion/comment-page-1/#comment-782

> And your preference for systemd doesn't obligate your distro of
> choice to change to it as the *default* init system.

What is a default in a distro with meta choices anyway? Yes, choice:

https://bugs.gentoo.org/show_bug.cgi?id=482702

> Again, we are just insisting that systemd proponents be prevented
> from forcing gentoo into a situation where we are *forced* to switch
> to systemd for the *default* init system.

While it is something to worry about; however, it's only happened once
and temporarily for GNOME (decided on by our maintainers), this has no
implication that this will happen much more beyond that. There are
people that are going to actively prevent that if it does happen.

> > Hence the general case above. If you want to use foo without using
> > bar, but the upstream and package maintainers of foo want to use
> > bar, then it's _your_ responsibility to make foo work without bar.
> > PERIOD.
> 
> I agree... so, if *you* want to use systemd, it is *your*
> reponsibility to make systemd work without impacting existing gentoo
> users

The impact, if any, is kept as minimal as possible; Gentoo, as stated
by it philosophy, about page and documentation is a meta distribution
which implies we attempt to support choices. Sometimes this means that
minimal adjustments need to be made to support multiple choices.

> *or* the fact that gentoo has selected OpenRC as it's default init
> system.

It's rather a consequence than a fact; for it to be a fact, there needs
to be an accepted motion from an higher instance stating it to be so.

> This isn't about individual packages. It is about one of the choices 
> that *Distro's* must make - in this case, regarding something very 
> significant (the choice of what to use as the default init system).

Both (separate stage3's), or none at all (stage<3); are also options. :)

> We, again, are simply insisting that it is the responsibility of the 
> developers of systemd to *not* create situations where they *force* 
> other distro's into *impossible* *situations* where they are *forced*
> to switch their init systems or have basic system packages stop
> working.

It are the consumers, to some extent even the packagers, that do this.

> The best way for gentoo, as a distro, to protect its users and it's 
> ecosystem, is to provide a sane, managed approach for systemd
> proponents to get systemd added to gentoo as a formally supported
> *optional* init system.

+1

> Then, and only then, can it be judged on its *merits*,

+1

> and then and  *only* then should it (imnsho) ever be considered as a
> potential candidate for being made a new *default*.

-1; unless, well, it has lost its "controversial" status in the future.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 20/03/2014 20:57, Tom Wijsman wrote:
> On Sat, 22 Feb 2014 19:46:42 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> eselect manages config options between different implementation of a
>> thing. Usually by tweaking symlinks. Switching init OpenRC <-> SystemD
>> involves resetting uSE flags and recompiling some fundamental stuff.
>> That exercise is unlikely to ever go into eselect.
> 
> Well, running systemd now I can reboot into OpenRC; it just works.

How is this done?


> 
>> The devs on gentoo-dev already nuked the idea of a gentoo profile as
>> such, it's not worth the effort and causes an explosion of profiles.
> 
> It's happening, `find /usr/portage/profiles/ -name '*systemd*'`; does
> it have any consequences that are worth thinking through?

As it stands now exactly, none. I only checked one profile:

default/linux/amd64/13.0/desktop/kde/

and that consists of one file - parent.
It lists .. and targets/systemd as parents. Which is easy enough as long
as the idea of systemd with kde stays exactly like that - the strict
union of kde and systemd profiles. Right now, a few line script can
create those profiles, will it always be that way?

What are the chances of LXDE and/or XFCE getting their own profiles like
Gnome and KDE? If they do, and they warrant a systemd sub-profile, then
the number of updates increases quite a lot. I've seen this kind of
thing happen many times where the number opf combinations quickly gets
out of control and becomes scary maintenance.

It's a pity Gentoo doesn't support multiple profiles (just keep enabling
extra till you get what you want or portage finds a conflict). That
would make new profile settings much easier. It's probably not supported
for the same reason most languages don;t go multiple inheritance. Oh well


>> Conceptually, it is rather similar to switching between nouveau and
>> nvidia. That doesn't have eselect support[1] or profiles.
> 
> Well, running NVIDIA now I can reboot with a simple script[1] put
> in /etc/local.d/nvidia.start (with execute permission); this works for
> me on both OpenRC and systemd, I'd say it is easy to do. Perhaps it can
> even be made more easy by rewriting the Xorg configuration to be device
> aware and therefore not needing the steps shown in this script.
> 
>  [1]: https://gist.github.com/TomWij/a13abacfb74999c10957

Yeah, you'd really need to make it work with one unchanging xorg.conf.
And that first line of code - relying on "-nvidia" being in
/proc/cmdline - wtf is that? :-)

Such, um, butcher hacks work OK on your machine but sure ain't

production ready

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Thu, 20 Mar 2014 21:00:27 +0100 Tom Wijsman wrote:
> > OpenRC is default in Gentoo now, and it is my best hope it will be.
> 
> Do you have a source that backs up this claim?

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6

> It comes as part of
> stage3, but a systemd stage3 is being worked on[1]; however, it has only
> temporarily been in the @system set (due to functions.sh[2] which is now
> split) and will soon be removed from it.
> 
>  [1]: https://bugs.gentoo.org/show_bug.cgi?id=482702

If these stage will be alternative, I'm OK with this. If it will be
the only one available, many people will have to say Gentoo good
bye.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Thu, 20 Mar 2014 22:22:22 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 20/03/2014 20:57, Tom Wijsman wrote:
>
> > Well, running systemd now I can reboot into OpenRC; it just works.
> 
> How is this done?

Here, two GRUB entries; alternatively, eselect init to switch symlinks.

> > It's happening, `find /usr/portage/profiles/ -name '*systemd*'`;
> > does it have any consequences that are worth thinking through?
> 
> As it stands now exactly, none. I only checked one profile:

Good, as you describe after this (cut out), I get the impression that
the opposite is the case and there are not enough; a solution to that
exists elwhere, in Funtoo, check out their Flavors and Mix-ins:

http://www.funtoo.org/Flavors_and_Mix-ins

Would be nice to have this on Gentoo.

> > Well, running NVIDIA now I can reboot with a simple script[1] put
> > in /etc/local.d/nvidia.start (with execute permission); this works
> > for me on both OpenRC and systemd, I'd say it is easy to do.
> > Perhaps it can even be made more easy by rewriting the Xorg
> > configuration to be device aware and therefore not needing the
> > steps shown in this script.
> > 
> >  [1]: https://gist.github.com/TomWij/a13abacfb74999c10957
> 
> Yeah, you'd really need to make it work with one unchanging xorg.conf.

Haven't tried; but given it works, it's something that I delay doing.

> And that first line of code - relying on "-nvidia" being in
> /proc/cmdline - wtf is that? :-)

Magic. :D
 
> Such, um, butcher hacks work OK on your machine but sure ain't
> 
> production ready

Maybe you mean packaging ready; as for production on your own servers
and desktops, I think it is ready enough. But YMMV.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Fri, 21 Mar 2014 02:27:11 +0600
Andrew Savchenko <bircoph@gmail.com> wrote:

> On Thu, 20 Mar 2014 21:00:27 +0100 Tom Wijsman wrote:
> > > OpenRC is default in Gentoo now, and it is my best hope it will
> > > be.
> > 
> > Do you have a source that backs up this claim?
> 
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6

That is documentation; it being listed as a default there is by the
consequence of it having been present there, whether it is decided to
be the default is another story (not found grepping council meetings).

> > It comes as part of
> > stage3, but a systemd stage3 is being worked on[1]; however, it has
> > only temporarily been in the @system set (due to functions.sh[2]
> > which is now split) and will soon be removed from it.
> > 
> >  [1]: https://bugs.gentoo.org/show_bug.cgi?id=482702
> 
> If these stage will be alternative, I'm OK with this. If it will be
> the only one available, many people will have to say Gentoo good
> bye.

Yes, alternative.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 3/20/2014 4:00 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 21 Feb 2014 09:53:51 +0400
> Andrew Savchenko <bircoph@gmail.com> wrote:
>> OpenRC is default in Gentoo now, and it is my best hope it will be.

> Do you have a source that backs up this claim?

Are you seriously challenging the FACT that OpenRC is the default init 
system in gentoo?

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 20/03/2014 22:33, Tom Wijsman wrote:
> Good, as you describe after this (cut out), I get the impression that
> the opposite is the case and there are not enough; a solution to that
> exists elwhere, in Funtoo, check out their Flavors and Mix-ins:
> 
> http://www.funtoo.org/Flavors_and_Mix-ins
> 
> Would be nice to have this on Gentoo.


Oooh, like in Django? Yes, I like that idea a lot.

I think of mix-ins like I think of java interfaces - wonderful idea,
easy to use, really hard to get them wrong

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:

Tom - please STOP CC'ing me on these emails.

I am on the list and don't need two copies.

Use 'Reply-To-List' function (or equivalent - or worst case, delete my 
direct email manually yourself) in your email program.

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[»Q«]

On Thu, 20 Mar 2014 22:15:32 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Fri, 21 Mar 2014 02:27:11 +0600
> Andrew Savchenko <bircoph@gmail.com> wrote:
> 
> > On Thu, 20 Mar 2014 21:00:27 +0100 Tom Wijsman wrote:  
> > > > OpenRC is default in Gentoo now, and it is my best hope it will
> > > > be.  
> > > 
> > > Do you have a source that backs up this claim?  
> > 
> > http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6  
> 
> That is documentation; it being listed as a default there is by the
> consequence of it having been present there, whether it is decided to
> be the default is another story (not found grepping council meetings).

Why should Gentoo have a default?  ISTM the only good reason is that
not having a default would make the documentation a lot more
complicated.

Re: Providing a path for systemd on gentoo - 'profiles', or 'eselect module'? - WAS Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Thu, 20 Mar 2014 22:22:22 +0200, Alan McKinnon wrote:

> > Well, running systemd now I can reboot into OpenRC; it just works.  
> 
> How is this done?

Simply by booting without init=. although some packages have been built
with USE="systemd" they still work when booting using openrc. Of course,
systemd is still present on the system, even if the PID1 process is not
running.

Incidentally, I discovered today that Linux Mint Debian Edition uses
classic init, but has systemd installed. All you need to switch over is
add the init= kernel option.


-- 
Neil Bothwick

A. Top posters.
Q. What is the most annoying thing on Usenet?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
> Why should Gentoo have a default?

Defaults are always a good idea - as long as they are reasonable and 
rational.

> ISTM the only good reason is that not having a default would make the
> documentation a lot more complicated.

Documentation, *and* the install process itself.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 06:37:20 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
> > Why should Gentoo have a default?
> 
> Defaults are always a good idea - as long as they are reasonable and 
> rational.

Depends on how you think about it; one could claim a DE as default as
reasonable and rational going one way, one could also claim something
like LFS or stage1 or so to be reasonable and rational. I think the
init system, as it becomes more of a choice, is on the edge here...

> > ISTM the only good reason is that not having a default would make
> > the documentation a lot more complicated.
> 
> Documentation, *and* the install process itself.

It's just one extra choice; so, that takes maybe a few minutes. It's a
choice one would have to eventually make anyway; so, better do it early
and have it right at once instead of having to do a more complicated
migration later on.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Thu, 20 Mar 2014 17:23:05 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 3/20/2014 4:00 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> > On Fri, 21 Feb 2014 09:53:51 +0400
> > Andrew Savchenko <bircoph@gmail.com> wrote:
> >> OpenRC is default in Gentoo now, and it is my best hope it will be.
> 
> > Do you have a source that backs up this claim?
> 
> Are you seriously challenging the FACT that OpenRC is the default
> init system in gentoo?

Depends on how you define "default"; because as far as can be seen,
it is by consequence rather than by decision.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Thu, 20 Mar 2014 17:25:18 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> 
> Tom - please STOP CC'ing me on these emails.
> 
> I am on the list and don't need two copies.
>
> Use 'Reply-To-List' function (or equivalent - or worst case, delete
> my direct email manually yourself) in your email program.

Like everyone else, use the 'Filter duplicates' function in your email
program or procmail; these requests aren't remembered, given that email
programs don't provide a function to do this selectively.

For more insight:

http://www.unicom.com/pw/reply-to-harmful.html
http://woozle.org/~neale/papers/reply-to-still-harmful.html

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Tue, 18 Feb 2014 19:32:28 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> A login daemon should be started by the init system, not be an
> integral part of it. What happens when logind no longer fulfils
> developers needs, as is the case with ConsoleKit now, how can it be
> replaced with an improved service when it is so closely tied to the
> init system.

It is started by the init system, as evidenced by the presence of
systemd-logind.service as well as there being a separate systemd-logind
executable; it is simply replaced by not starting the service, instead,
starting another service that fits those needs.

Also: http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n798

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Tue, 18 Feb 2014 10:54:55 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote:
> > On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> > <volkerarmin@googlemail.com> wrote:
> >> oh? I can pipe that output into cat or any any daemon I like?
> >> Doesn't look like so.
> >
> > But it does, you can "cat" with journalctl; it's one of its output
> > options:
> >
> >        -o, --output=
> >            cat
> >                generates a very terse output only showing the actual
> > message of each journal entry with no meta data, not even a
> > timestamp.
> 
> As I do not have systemd installed on any machine, I can't check the
> man-pages.

http://cgit.freedesktop.org/systemd/systemd/tree/man

> But, if that is the only method to get parseable text from journalctl,
> then that is less then useless.

Why? There are other output methods. See the man pages...

> I would expect an export option providing the same detail level as I
> currently find in /var/log/messages.

That's what you can control with the various options of -o.

> A timestamp is a minimum required for logging system output.

Depends on how you are processing that output.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Wed, 19 Feb 2014 09:50:07 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> It all sounds too much like the MS Windows Event-viewer to me.
> Too many events with no usefull logging information (And I am
> referring to OS-level messages as to why default services are not
> starting)

The MS Windows Event-viewer has very nice filtering capabilities;
beyond that, the detailed information gives you the error code that you
can look up in the documentation.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sun, 16 Feb 2014 23:00:43 +0400
"Yuri K. Shatroff" <yks-uno@yandex.ru> wrote:

> I wonder why all systemd's fancy stuff hasn't yet been integrated
> into any existing init system, because of theoretical impossibility
> or just practical uselessness?

A lot of it is being integrated in some as we speak; however, other init
systems are slow to catch up. In the last two months; as you can see,
there haven't been meaningful commits to OpenRC other than small
documentation fixes. The shortlog allows me to see the entire last year.

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=log
http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Wed, 19 Feb 2014 07:57:06 -0500
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> Getting the Gentoo Council behind this idea, and providing an
> officially supported - or maybe a better term is *mandated* - process
> whereby systemd proponents can create and then maintain new systemd
> versions of any existing profiles.
> 
> I guess maybe it is time to go open a bug about this?
> 
> I would be happy to do this, but maybe it would be better if someone
> who has much more knowledge of the inner workings of the Gentoo
> Council and whatever process governs things like this to do it?

Wait on the gentoo-project ML for a mail gathering agenda items; once
that happens, reply to it clearly explaining your request and what you
would want them to discuss or vote on. Then you can watch and/or
participate in the next meeting (they announce when that is there)
and/or read up about their decision in the log and/or summary as they
come online; for further details, you can read up here:

http://wiki.gentoo.org/wiki/Project:Council

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On 21 March 2014 12:24:04 CET, Tom Wijsman <TomWij@gentoo.org> wrote:
>On Tue, 18 Feb 2014 10:54:55 +0100
>"J. Roeleveld" <joost@antarean.org> wrote:
>
>> On Sun, February 16, 2014 22:16, Canek Peláez Valdés wrote:
>> > On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
>> > <volkerarmin@googlemail.com> wrote:
>> >> oh? I can pipe that output into cat or any any daemon I like?
>> >> Doesn't look like so.
>> >
>> > But it does, you can "cat" with journalctl; it's one of its output
>> > options:
>> >
>> >        -o, --output=
>> >            cat
>> >                generates a very terse output only showing the
>actual
>> > message of each journal entry with no meta data, not even a
>> > timestamp.
>> 
>> As I do not have systemd installed on any machine, I can't check the
>> man-pages.
>
>http://cgit.freedesktop.org/systemd/systemd/tree/man
>
>> But, if that is the only method to get parseable text from
>journalctl,
>> then that is less then useless.
>
>Why? There are other output methods. See the man pages...
>
>> I would expect an export option providing the same detail level as I
>> currently find in /var/log/messages.
>
>That's what you can control with the various options of -o.
>
>> A timestamp is a minimum required for logging system output.
>
>Depends on how you are processing that output.

Tom,

Please reply to list. No need to include me in the recipient list.

Also, no need to reopen a closed mail thread with replies that re-iterate already mentioned information. Canek said the same in his replies.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 12:50:23 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> Tom,
> 
> Please reply to list. No need to include me in the recipient list.

Please filter duplicate mails. No need to tell each other this.

http://www.unicom.com/pw/reply-to-harmful.html
http://woozle.org/~neale/papers/reply-to-still-harmful.html

> Also, no need to reopen a closed mail

A thread can't be closed by its individuals; you can choose to not
reply, but that doesn't withhold the ability for others to reply.

> thread with replies that re-iterate already mentioned information.
> Canek said the same in his replies.

Yes, I saw that after sending this mail; for most replies I do I check
up on it in advance, in this case I missed and/or forgot. Sorry.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Tom Wijsman wrote:
> On Thu, 20 Mar 2014 17:25:18 -0400
> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>
>> On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>
>> Tom - please STOP CC'ing me on these emails.
>>
>> I am on the list and don't need two copies.
>>
>> Use 'Reply-To-List' function (or equivalent - or worst case, delete
>> my direct email manually yourself) in your email program.
> Like everyone else, use the 'Filter duplicates' function in your email
> program or procmail; these requests aren't remembered, given that email
> programs don't provide a function to do this selectively.
>
> For more insight:
>
> http://www.unicom.com/pw/reply-to-harmful.html
> http://woozle.org/~neale/papers/reply-to-still-harmful.html
>


So let's get this straight.  You want most everyone on this list to
change what they have to do to remove dups caused by you, instead of you
changing what you do to fix the problem?  To put it another way, you
want to inconvenience everyone else instead of doing things the way
everyone else does it and has done it for a long time? 

Here's a hint.  I can see a LOT of people adding you to their
blacklist.  You could very well end up talking to yourself on this
mailing list.  Why not send messages in html while at it?  That should
finish off you getting your messages read. 

Just something to think about. 

Dale

:-)  :-) 

P. S.  CC this message to me and I get a dup, I won't get the next one. 
I can fix the issue for you on a more permanent basis. 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Fri, 21 Mar 2014 12:13:28 +0100, Tom Wijsman wrote:

> > Use 'Reply-To-List' function (or equivalent - or worst case, delete
> > my direct email manually yourself) in your email program.  
> 
> Like everyone else, use the 'Filter duplicates' function in your email
> program or procmail; these requests aren't remembered, given that email
> programs don't provide a function to do this selectively.

Don't they? Then why did you only get one copy of this reply, via the
list? Most posters here do not have this problem, 

Of course, if you don't want people to bother reading your mails,
continue to piss them off.


-- 
Neil Bothwick

C Error #011: First C Program, huh?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Fri, March 21, 2014 12:59, Tom Wijsman wrote:
> On Fri, 21 Mar 2014 12:50:23 +0100
> "J. Roeleveld" <joost@antarean.org> wrote:
>
>> Tom,
>>
>> Please reply to list. No need to include me in the recipient list.
>
> Please filter duplicate mails. No need to tell each other this.

I filter on the server, using SIEVE-scripts.
Please provide the correct syntax I need to do this.

You are the only one causing duplicate emails, all others on this list do
NOT cause duplicate emails.
This means the cause is on your side and the solution should then also be
on your side.

> http://www.unicom.com/pw/reply-to-harmful.html
> http://woozle.org/~neale/papers/reply-to-still-harmful.html

I disagree with those. Seen those arguments before along with the opposite
versions. Mailing lists where a reply does not work are broken. Mailing
lists where I always end up with duplicate replies don't stay used by
myself for very long.

>> Also, no need to reopen a closed mail
>
> A thread can't be closed by its individuals; you can choose to not
> reply, but that doesn't withhold the ability for others to reply.

True, but a mail-thread that hasn't had a reply for over a month is
usually considered closed. It's nice that you decide to catch up with your
emails, but please then take care not to flood inboxes as well.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 07:10:49 -0500
Dale <rdalek1967@gmail.com> wrote:

> So let's get this straight.  You want most everyone on this list to
> change what they have to do to remove dups caused by you, instead of
> you changing what you do to fix the problem?

Everyone else is okay with it, as only one in a thousand speaks up
about it; the problem rather is with that 0.1% than that it is with me,
as I just use mailing lists as they are supposed to be used.

> To put it another way, you want to inconvenience everyone else
> instead of doing things the way everyone else does it and has done it
> for a long time? 

That's what the Reply-To header mungling does; it makes you unable to
tell me through the Reply-To header what you want, and as a result I
need to use the default than to be able to automatically respect it.

As can be seen, that is an automatic guarantee that it will reach you.

Just as well as the automatic guarantee that the same Message ID is the
same message; and thus, your mail client should be filtering duplicates.

> Here's a hint.  I can see a LOT of people adding you to their
> blacklist.  You could very well end up talking to yourself on this
> mailing list.

Here's a hint. Lots of people appear to respond to me.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Fri, 21 Mar 2014 12:27:09 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Fri, 21 Mar 2014 12:13:28 +0100, Tom Wijsman wrote:
> 
> > > Use 'Reply-To-List' function (or equivalent - or worst case,
> > > delete my direct email manually yourself) in your email program.  
> > 
> > Like everyone else, use the 'Filter duplicates' function in your
> > email program or procmail; these requests aren't remembered, given
> > that email programs don't provide a function to do this selectively.
> 
> Don't they? Then why did you only get one copy of this reply, via the
> list? Most posters here do not have this problem, 

Did I receive a reply? Who says I am even subscribed to the list?

> Of course, if you don't want people to bother reading your mails,
> continue to piss them off.

All I'm doing is making sure this message gets to you; every notion you
give to it beyond that, is what that 0.1% thinks of it. Not my problem.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Poison BL.]

On Fri, Mar 21, 2014 at 8:49 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Fri, 21 Mar 2014 12:27:09 +0000
> Neil Bothwick <neil@digimed.co.uk> wrote:
>
>> On Fri, 21 Mar 2014 12:13:28 +0100, Tom Wijsman wrote:
>>
>> > > Use 'Reply-To-List' function (or equivalent - or worst case,
>> > > delete my direct email manually yourself) in your email program.
>> >
>> > Like everyone else, use the 'Filter duplicates' function in your
>> > email program or procmail; these requests aren't remembered, given
>> > that email programs don't provide a function to do this selectively.
>>
>> Don't they? Then why did you only get one copy of this reply, via the
>> list? Most posters here do not have this problem,
>
> Did I receive a reply? Who says I am even subscribed to the list?
>
>> Of course, if you don't want people to bother reading your mails,
>> continue to piss them off.
>
> All I'm doing is making sure this message gets to you; every notion you
> give to it beyond that, is what that 0.1% thinks of it. Not my problem.
>
> --
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Just my 2c as one of the others who doesn't generally reply to what,
at face value, seemed an awful lot more combative/trolling of a tone
than actually useful (disregard != compliance on the internet),
fighting on the topic of 'proper use of mailing lists' when you're
standing in stark contrast to the configuration of the mailing list
you're using to do it, and in the process, telling everyone (many of
which have been around here helping other users for many, many, years)
that they're wrong for using the list they've been using in the manner
they've been using it... when I see your name appear the first time as
long ago as last Dec., is rather on the arrogant side at the least
(I'm not certain if you've been around -dev or another longer, as I
don't believe I'm subscribed on that one). If you're really hellbent
on getting the configuration of the list changed, feel free to take it
up with the person who configures the list, rather than approaching it
by being condescending to the people who consistently use it.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 13:41:54 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> On Fri, March 21, 2014 12:59, Tom Wijsman wrote:
> > On Fri, 21 Mar 2014 12:50:23 +0100
> > "J. Roeleveld" <joost@antarean.org> wrote:
> >
> >> Tom,
> >>
> >> Please reply to list. No need to include me in the recipient list.
> >
> > Please filter duplicate mails. No need to tell each other this.
> 
> I filter on the server, using SIEVE-scripts.
> Please provide the correct syntax I need to do this.

The vnd.dovecot.duplicate extension can be used to do this, RFC:

    http://hg.rename-it.nl/dovecot-2.1-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt

It is designed exactly for this purpose, quote from the introduction:

    Duplicate deliveries are a common side-effect of being subscribed
    to a mailing list.

Example correct syntax:

    require ["vnd.dovecot.duplicate", "fileinto", "mailbox"];

    if duplicate {
        fileinto :create "Trash/Duplicate";
    }

This will move duplicates to Trash/Duplicate, given that you enable the
vnd.dovecot.duplicate extension; I use a similar rule in procmail.

> You are the only one causing duplicate emails, all others on this
> list do NOT cause duplicate emails.

That's because some people here are users that don't commonly use
bigger mailing lists and thus have no such filter in place; however,
when you get to participate in bigger mailing lists, you will get such
duplicate mails by design if you don't have a filter. Take for example
the LKML, where it is common practice that relevant mailing lists as
well as individuals are CC-ed; you'll get a dupe as one of either.

Being the sender of a message, however, some mailing lists allow you to
control whether you want to be CC-ed; this can be done by setting a
"Reply-To header", but in this case it is always overridden which
removes the ability to guarantee you'll receive the message.

There are other participants on the Gentoo mailing lists that
participate in other mailing lists too; and when met with Reply-To
mungling, they do the same approach. eg. Michał Górny (mgorny)

> This means the cause is on your side and the solution should then
> also be on your side.

The goal is to ensure people receive their mail; if I were to make a
solution on my sight, it voids that goal as the guarantee is gone.

> > http://www.unicom.com/pw/reply-to-harmful.html
> > http://woozle.org/~neale/papers/reply-to-still-harmful.html
> 
> I disagree with those. Seen those arguments before along with the
> opposite versions. Mailing lists where a reply does not work are
> broken. Mailing lists where I always end up with duplicate replies
> don't stay used by myself for very long.

Given a present filter, I use any mailing list; I don't let technical
differences in the software being used overcome the ability to state
something on a mailing list, and if a technical difference does matter
to someone (0.1% in this case) I expect them to adapt. This ain't a
place where "One True Way" is to be enforced; as you can see, I very
well consider the standard reply button to be broken...

> >> Also, no need to reopen a closed mail
> >
> > A thread can't be closed by its individuals; you can choose to not
> > reply, but that doesn't withhold the ability for others to reply.
> 
> True, but a mail-thread that hasn't had a reply for over a month is
> usually considered closed. It's nice that you decide to catch up with
> your emails, but please then take care not to flood inboxes as well.

Similar to above, right click and "ignore thread" could be used as
well as "sort / group by thread"; as without both features, there's no
dam in place to avoid the flood from happening.

As for the river / sea, there's no way to convince the river / sea to
go away; it'll be there, even if you could use a bucket to remove me,
there'll be another person or so tomorrow.

In comparison, on the LKML you will get replies one or more months
later; if you there then reply claiming a thread is closed, it'll be
perceived as everything but that...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 09:13:27 -0400
"Poison BL." <poisonbl@gmail.com> wrote:

> fighting on the topic of 'proper use of mailing lists' when you're
> standing in stark contrast to the configuration of the mailing list
> you're using to do it,

Which fight? It is a short notice as to why it is being done, as well
as what can be done to make a change. Convincing individually isn't.

> and in the process, telling everyone (many of which have been around
> here helping other users for many, many, years) that they're wrong
> for using the list they've been using in the manner they've been
> using it...

Words are being turned around here, I've never said someone is wrong;
however, I provided filtering as an option to them to consider.

> when I see your name appear the first time as long ago as
> last Dec., is rather on the arrogant side at the least (I'm not
> certain if you've been around -dev or another longer, as I don't
> believe I'm subscribed on that one).

There are more mailing lists and communication mediums; the reason
I've not replied much in this one since last year, is because I've let
this inbox grow to ~1000 unread mails or so which I'm progressing now.

> If you're really hellbent on getting the configuration of the list
> changed, feel free to take it up with the person who configures the
> list, rather than approaching it by being condescending to the people
> who consistently use it.

That's for those that have a problem with it to do; as well a getting
it confirmed that a certain way of responding is required, there's been
nothing said about it when mails of mine went out to persons from the
infrastructure team on the gentoo-dev ML and neither by other devs.

Developers recommend each other to use a rule, and everyone uses it;
it might be a side effect of procmail being available on our dev SSH,
but in any case it works out well for every developer, see this link:

http://wiki.gentoo.org/wiki/Procmail

"The mailing list etiquette requires people to CC all the people
involved in a particular thread in replies to the mailing list, in case
any of them is not subscribed."

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Fri, March 21, 2014 14:20, Tom Wijsman wrote:
> On Fri, 21 Mar 2014 13:41:54 +0100
> "J. Roeleveld" <joost@antarean.org> wrote:
>
>> On Fri, March 21, 2014 12:59, Tom Wijsman wrote:
>> > On Fri, 21 Mar 2014 12:50:23 +0100
>> > "J. Roeleveld" <joost@antarean.org> wrote:
>> >
>> >> Tom,
>> >>
>> >> Please reply to list. No need to include me in the recipient list.
>> >
>> > Please filter duplicate mails. No need to tell each other this.
>>
>> I filter on the server, using SIEVE-scripts.
>> Please provide the correct syntax I need to do this.
>
> The vnd.dovecot.duplicate extension can be used to do this, RFC:
>
>     http://hg.rename-it.nl/dovecot-2.1-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt
>
> It is designed exactly for this purpose, quote from the introduction:
>
>     Duplicate deliveries are a common side-effect of being subscribed
>     to a mailing list.
>
> Example correct syntax:
>
>     require ["vnd.dovecot.duplicate", "fileinto", "mailbox"];
>
>     if duplicate {
>         fileinto :create "Trash/Duplicate";
>     }

Is that one included in the Cyrus ebuild?

> This will move duplicates to Trash/Duplicate, given that you enable the
> vnd.dovecot.duplicate extension; I use a similar rule in procmail.

I ONLY want duplicates that would end up in my inbox to be filtered.
If an email is sent to 2 or more mailing lists, they should end up in each
relevant mailing list folder.

>> You are the only one causing duplicate emails, all others on this
>> list do NOT cause duplicate emails.
>
> That's because some people here are users that don't commonly use
> bigger mailing lists and thus have no such filter in place; however,
> when you get to participate in bigger mailing lists, you will get such
> duplicate mails by design if you don't have a filter. Take for example
> the LKML, where it is common practice that relevant mailing lists as
> well as individuals are CC-ed; you'll get a dupe as one of either.

With LKML, most people don't stay subscribed for very long as their
mailboxes overflow. On this list, the general consensus is that you reply
to list only unless specifically requested otherwise.

> Being the sender of a message, however, some mailing lists allow you to
> control whether you want to be CC-ed; this can be done by setting a
> "Reply-To header", but in this case it is always overridden which
> removes the ability to guarantee you'll receive the message.

I am subscribed, so no need to add me to the CC.
If I am really interested in the reply and I would not be in the list, I
would check the archives, which are updated fast enough for the purpose.

> There are other participants on the Gentoo mailing lists that
> participate in other mailing lists too; and when met with Reply-To
> mungling, they do the same approach. eg. Michał Górny (mgorny)
>
>> This means the cause is on your side and the solution should then
>> also be on your side.
>
> The goal is to ensure people receive their mail; if I were to make a
> solution on my sight, it voids that goal as the guarantee is gone.

The goal only makes sense when replying to emails that are still relevant.
A discussion that is over a month old is usually no longer relevant.
Especially if the email only contains information that already was sent.

>> > http://www.unicom.com/pw/reply-to-harmful.html
>> > http://woozle.org/~neale/papers/reply-to-still-harmful.html
>>
>> I disagree with those. Seen those arguments before along with the
>> opposite versions. Mailing lists where a reply does not work are
>> broken. Mailing lists where I always end up with duplicate replies
>> don't stay used by myself for very long.
>
> Given a present filter, I use any mailing list; I don't let technical
> differences in the software being used overcome the ability to state
> something on a mailing list, and if a technical difference does matter
> to someone (0.1% in this case) I expect them to adapt. This ain't a
> place where "One True Way" is to be enforced; as you can see, I very
> well consider the standard reply button to be broken...

Still waiting for a filter that works on my server.

>> >> Also, no need to reopen a closed mail
>> >
>> > A thread can't be closed by its individuals; you can choose to not
>> > reply, but that doesn't withhold the ability for others to reply.
>>
>> True, but a mail-thread that hasn't had a reply for over a month is
>> usually considered closed. It's nice that you decide to catch up with
>> your emails, but please then take care not to flood inboxes as well.
>
> Similar to above, right click and "ignore thread" could be used as
> well as "sort / group by thread"; as without both features, there's no
> dam in place to avoid the flood from happening.

Filtering out your emails fully also would avoid this happening.

> As for the river / sea, there's no way to convince the river / sea to
> go away; it'll be there, even if you could use a bucket to remove me,
> there'll be another person or so tomorrow.

On this list, you (people who insist on CC-ing the world) are the minority.

> In comparison, on the LKML you will get replies one or more months
> later; if you there then reply claiming a thread is closed, it'll be
> perceived as everything but that...

I would expect the reply to make sense when it comes.

--
Joost

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 15:06:12 +0100
"J. Roeleveld" <joost@antarean.org> wrote:

> Is that one included in the Cyrus ebuild?

In Cyrus it is an actual feature, see the (first) FAQ[1] entry about
Duplicate Delivery Surpression; in imapd.conf you can do

    duplicatesuppression: 1

to enable this. It might be that because this is an actual feature that
the extension isn't implemented; unpacking the source tarball, then
insensitive case grepping for 'dupl', I only find the above feature.

 [1]: https://cyrusimap.org/mediawiki/index.php/FAQ

> I ONLY want duplicates that would end up in my inbox to be filtered.
> If an email is sent to 2 or more mailing lists, they should end up in
> each relevant mailing list folder.

The procmail filter we have neatly does this by checking the List-Id
header; maybe this can be mimicked in a Sieve rule, the rule is simple.

> With LKML, most people don't stay subscribed for very long as their
> mailboxes overflow. On this list, the general consensus is that you
> reply to list only unless specifically requested otherwise.

It's possible to stay subscribed with strict filtering, its
reading volume to me is in terms of unread mail currently 5 times as
much as this ML; however, I scroll more through the mails there than I
do here which makes the effort to process both nearly equal.

With a higher amount of mailing lists to follow I don't keep a list of
exceptions; and therefore, to keep it simple, do the same everywhere.

Information overflow stays manageable for me if I keep things simple;
if I however would start to add manual matching techniques to that, it
would become much more unmanageable as instead of being effective I
suddenly start doing something what our software is supposed to do.

> I am subscribed, so no need to add me to the CC.

As said above, I could put this on a list; but I'll forget about it.

> If I am really interested in the reply and I would not be in the
> list, I would check the archives, which are updated fast enough for
> the purpose.

That is only so if you expect and/or are aware of the reply.
 
> The goal only makes sense when replying to emails that are still
> relevant. A discussion that is over a month old is usually no longer
> relevant.

Not much has changed since then; and thus, it is still recent enough.
 
> Filtering out your emails fully also would avoid this happening.

It is quite effective.
 
> > As for the river / sea, there's no way to convince the river / sea
> > to go away; it'll be there, even if you could use a bucket to
> > remove me, there'll be another person or so tomorrow.
> 
> On this list, you (people who insist on CC-ing the world) are the
> minority.

On this world, this list (where people that I can count on my fingers
insist on not being CC-ed) is a minority.

Regardless of both being a minority, they'll continue to be present.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

J. Roeleveld wrote:
> I filter on the server, using SIEVE-scripts. Please provide the
> correct syntax I need to do this. You are the only one causing
> duplicate emails, all others on this list do NOT cause duplicate
> emails. This means the cause is on your side and the solution should
> then also be on your side.
>> http://www.unicom.com/pw/reply-to-harmful.html
>> http://woozle.org/~neale/papers/reply-to-still-harmful.html
> I disagree with those. Seen those arguments before along with the opposite
> versions. Mailing lists where a reply does not work are broken. Mailing
> lists where I always end up with duplicate replies don't stay used by
> myself for very long.
>

+1  This is no different than a person sending a HTML email.  This
mailing list doesn't like them and it is the sender that should change
their settings to stop it from happening.  We may make exceptions for
those using cell phones who can not change it but when it can be changed
by the sender, it should be changed by them. 

Dale

:-)  :-) 


-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Tom Wijsman wrote:
> On Fri, 21 Mar 2014 07:10:49 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>> So let's get this straight.  You want most everyone on this list to
>> change what they have to do to remove dups caused by you, instead of
>> you changing what you do to fix the problem?
> Everyone else is okay with it, as only one in a thousand speaks up
> about it; the problem rather is with that 0.1% than that it is with me,
> as I just use mailing lists as they are supposed to be used.

FYI.  Most people don't say anything, they just blacklist you.  After
that, you don't exist to them. 


>> To put it another way, you want to inconvenience everyone else
>> instead of doing things the way everyone else does it and has done it
>> for a long time? 
> That's what the Reply-To header mungling does; it makes you unable to
> tell me through the Reply-To header what you want, and as a result I
> need to use the default than to be able to automatically respect it.
>
> As can be seen, that is an automatic guarantee that it will reach you.
>
> Just as well as the automatic guarantee that the same Message ID is the
> same message; and thus, your mail client should be filtering duplicates.
>

To my knowledge, the only emails I have not got when someone sent to
this mailing list is when the mailing list server had problems and that
was a long long time ago.  You send a email to the list and the list
gets the email.  There is NO need to CC everyone so that they get dups. 
Period.  We don't need a CC guarantee. 


>> Here's a hint.  I can see a LOT of people adding you to their
>> blacklist.  You could very well end up talking to yourself on this
>> mailing list.
> Here's a hint. Lots of people appear to respond to me.
>

This is a COMMUNITY effort here and you seem to not want to be a part of
the community.  When I first came here, my email program sent html.  I
was told that HTML is not appreciated here.  Some even provided examples
of why it is not appreciated.  I asked how to change that, I was given
the help needed to change it and I have made sure that it remained that
way since.  There was a point in time where I changed software and
couldn't find the setting.  I asked if anyone knew where it was and got
the help needed to get it set back to plain text, as EVERYONE else does
on this list. 

If you don't want to be here by the standards set, say good bye.  I'm
trying to help you by telling you this.  People will blacklist you and
never say a word about it.  I suspect quite a few already has.  It would
be wise to change your way of handling this list or you will lose. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 3/21/2014 7:13 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 20 Mar 2014 17:25:18 -0400
> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>
>> On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>
>> Tom - please STOP CC'ing me on these emails.
>>
>> I am on the list and don't need two copies.
>>
>> Use 'Reply-To-List' function (or equivalent - or worst case, delete
>> my direct email manually yourself) in your email program.
>
> Like everyone else, use the 'Filter duplicates' function in your email
> program or procmail;

Fuck you Tom.

PLONK THE ARROGANT PRICK.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Poison BL. wrote:
> Just my 2c as one of the others who doesn't generally reply to what,
> at face value, seemed an awful lot more combative/trolling of a tone
> than actually useful (disregard != compliance on the internet),
> fighting on the topic of 'proper use of mailing lists' when you're
> standing in stark contrast to the configuration of the mailing list
> you're using to do it, and in the process, telling everyone (many of
> which have been around here helping other users for many, many, years)
> that they're wrong for using the list they've been using in the manner
> they've been using it... when I see your name appear the first time as
> long ago as last Dec., is rather on the arrogant side at the least
> (I'm not certain if you've been around -dev or another longer, as I
> don't believe I'm subscribed on that one). If you're really hellbent
> on getting the configuration of the list changed, feel free to take it
> up with the person who configures the list, rather than approaching it
> by being condescending to the people who consistently use it. 

+1  I see Tom being on a lot of peoples black list.  He's burning bridges. 

I been here since 2003 or 2004 if I recall correctly.  When I first came
here, I conformed my settings to what the people on this list wanted and
expected.  I was told the same thing people are telling Tom now. 
Failure to listen and adapt is not going to go well for Tom.  It seems
Tom wants everyone else to change because he refuses too and on top of
that, he thinks no one will do anything if he doesn't. 

I'll give this a day or two.  If it doesn't change, bye Tom.  That won't
just be for this list but also every Gentoo list you are on including -dev.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Tanstaafl wrote:
> On 3/21/2014 7:13 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>> On Thu, 20 Mar 2014 17:25:18 -0400
>> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>
>>> On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>>
>>> Tom - please STOP CC'ing me on these emails.
>>>
>>> I am on the list and don't need two copies.
>>>
>>> Use 'Reply-To-List' function (or equivalent - or worst case, delete
>>> my direct email manually yourself) in your email program.
>>
>> Like everyone else, use the 'Filter duplicates' function in your email
>> program or procmail;
>
> Fuck you Tom.
>
> PLONK THE ARROGANT PRICK.
>
>


There goes one.  Tom, you ever wonder how many people are doing the same
but not saying anything? 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 12:41:03 -0500
Dale <rdalek1967@gmail.com> wrote:

> FYI.  Most people don't say anything, they just blacklist you.  After
> that, you don't exist to them. 

Yes, that's up to those few; it could happen, but most respond instead.

> To my knowledge, the only emails I have not got when someone sent to
> this mailing list is when the mailing list server had problems and
> that was a long long time ago.  You send a email to the list and the
> list gets the email.  There is NO need to CC everyone so that they
> get dups. Period.

There is a need, see the previous mails about it; the need stays as is.

> We don't need a CC guarantee. 

I do, as I spend time on this; that time should have guaranteed results.

> This is a COMMUNITY effort here and you seem to not want to be a part
> of the community.

If it were true, I would stop my contributions and support here and now.

> If you don't want to be here by the standards set, say good bye.

The etiquette is the standard that I follow, it encourages this; it
is stepping away from that etiquette and thus results in "good bye":

http://article.gmane.org/gmane.linux.gentoo.user/273297

Consider that each time you tell some user to not CC or so on the ML,
you're actually sending an extra mail to a ton of people yourself;
whereas the mail telling that ignores the subject of the thread,
please consider to do this in an off-list reply with positive words.

> I'm trying to help you by telling you this.  People will blacklist
> you and never say a word about it.  I suspect quite a few already
> has.  It would be wise to change your way of handling this list or
> you will lose. 

And others try to help me by telling the opposite; so, when two
groups of people tell you to do something that conflicts, which one
would be picked? Well, pick the one that respects our etiquette; and
along that, the same one guarantees that my time is spent wise.

Similarly, would you spend time to keep asking this everytime it happens
by one or another individual or just simply filter it once and for all?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 21/03/2014 20:23, Dale wrote:
> Tanstaafl wrote:
>> On 3/21/2014 7:13 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>> On Thu, 20 Mar 2014 17:25:18 -0400
>>> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>>
>>>> On 3/20/2014 4:14 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>>>
>>>> Tom - please STOP CC'ing me on these emails.
>>>>
>>>> I am on the list and don't need two copies.
>>>>
>>>> Use 'Reply-To-List' function (or equivalent - or worst case, delete
>>>> my direct email manually yourself) in your email program.
>>>
>>> Like everyone else, use the 'Filter duplicates' function in your email
>>> program or procmail;
>>
>> Fuck you Tom.
>>
>> PLONK THE ARROGANT PRICK.
>>
>>
> 
> 
> There goes one.  Tom, you ever wonder how many people are doing the same
> but not saying anything? 


Judging by replies so far, I'd guess not many at all.

You can't possibly know how many will or will not plonk someone. In the
meantime Dale, I think you are projecting.

Chill out brother, chill out. Plenty stuff in the world more deserving
of attention than this.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Walter Dnes]

On Fri, Mar 21, 2014 at 02:29:48PM +0100, Tom Wijsman wrote

> http://wiki.gentoo.org/wiki/Procmail
> 
> "The mailing list etiquette requires people to CC all the people
> involved in a particular thread in replies to the mailing list, in case
> any of them is not subscribed."

  How does one send email to *THIS* list, without being subscribed in
the first place?  A bugzilla mailing list is a different matter.  A web
form bug submission goes to a list, which the submitter is probably not
subscribed to.  Developers do need to CC their replies to the original
submitter to let them know what's happening.  But I'm not aware of any
such mechanism on this list.  If someone is involved in a thread here,
then they've obviously subscribed here.  So the CC: is redundant.

  Speaking of procmail+formail, I use them to tame the lists that follow
Chip Rosenthal's ideas.  E.g., if this list did that, I would use...

:0 fhw
* ^X-BeenThere: gentoo-user@lists\.gentoo\.org
* !^Reply-To: gentoo-user@lists\.gentoo\.org
  | formail -i "Reply-To: gentoo-user@lists\.gentoo\.org (Gentoo users)"

  I do this to the few lists I run into that I want/need, which blindly
follow Chip's ideas.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 21/03/2014 23:57, Walter Dnes wrote:
> On Fri, Mar 21, 2014 at 02:29:48PM +0100, Tom Wijsman wrote
> 
>> http://wiki.gentoo.org/wiki/Procmail
>>
>> "The mailing list etiquette requires people to CC all the people
>> involved in a particular thread in replies to the mailing list, in case
>> any of them is not subscribed."
> 
>   How does one send email to *THIS* list, without being subscribed in
> the first place?  A bugzilla mailing list is a different matter.  A web
> form bug submission goes to a list, which the submitter is probably not
> subscribed to.  Developers do need to CC their replies to the original
> submitter to let them know what's happening.  But I'm not aware of any
> such mechanism on this list.  If someone is involved in a thread here,
> then they've obviously subscribed here.  So the CC: is redundant.
> 
>   Speaking of procmail+formail, I use them to tame the lists that follow
> Chip Rosenthal's ideas.  E.g., if this list did that, I would use...
> 
> :0 fhw
> * ^X-BeenThere: gentoo-user@lists\.gentoo\.org
> * !^Reply-To: gentoo-user@lists\.gentoo\.org
>   | formail -i "Reply-To: gentoo-user@lists\.gentoo\.org (Gentoo users)"
> 
>   I do this to the few lists I run into that I want/need, which blindly
> follow Chip's ideas.
> 


Chip Rosenthal? yeah, he's the "Reply-To munging considered harmful" fellow

Trouble is, he argues from a theoretical position and ignores what
people actually do with lists. There's two main uses:

1. a distribution mechanism to reach all subscribers and/or where you
don;t have to be subscribed to post. For these you really don't want to
munge Reply-To

2. A discussion forum. For these you do munge Reply-To: to be the list
so all discussion happens on-list and is visible to all

gentoo-user has always been the latter and all discussion always takes
place on-list. If some doc somewhere says otherwise, change the doc to
reflect reality.

I utterly fail to see why so many folks on the internet can't see why
there's two kinds of lists...   I think I'm going to compose an essay;

"Chip Rosenthal and his detractors all considered harmful"


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Fri, 21 Mar 2014 17:57:07 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> How does one send email to *THIS* list, without being subscribed in
> the first place?

You can do that on sites like GMANE; similarly, given a message ID,
you can request that specific from the mailing list daemon to land in
your inbox, which allows you even do a signed reply to it.

As you can see; there are people that want to participate only when
they are interested in it, rather than flood their mailing program.

Let's say you have a bug when you unmount a filesystem; so, you go look
on the LKML if there's something known about it. You'll find:

    http://article.gmane.org/gmane.linux.kernel/1671264

The thing is; you're not subscribed as you found it, yet you want to
reply to it without subscribing to its flood, what do? You send off a
single reply; then you expect someone that responds to CC you if that
person wants to tell / ask you something, otherwise you wouldn't know.

> But I'm not aware of any such mechanism on this list.  If someone is
> involved in a thread here, then they've obviously subscribed here.
> So the CC: is redundant.

Invisible things are hard to be aware of; you assume that the person is
CC-ed, however, the person may have found the thread through GMANE _or_
the person might have been unsubscribed by the moment you make a reply.

We see similar things happen on IRC; someone asks a question, 2 or 3
minutes later they are gone. Sometimes they ask a question, but receive
no answer so they are gone 20 or 30 minutes later. Similarly; we're now
a month later in this ML thread, who says people are still subscribed?

On IRC, if you pay notice to the many join/part/quits and don't filter
them, you can still spot that with awareness; however, on ML you can't.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 00:34:55 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> 2. A discussion forum. For these you do munge Reply-To: to be the list
> so all discussion happens on-list and is visible to all
> 
> gentoo-user has always been the latter and all discussion always takes
> place on-list. If some doc somewhere says otherwise, change the doc to
> reflect reality.

http://www.gentoo.org/main/en/lists.xml mentions it is about support
too, and people that are here to be supported don't necessarily want to
follow the discussion that comes along as well; thus unsubscribe
before an answer or not subscribe at all in the first place, they then
instead rely on receiving a mail regardless of that.

CC-ing ensures that the minutes spent on the answer make it reach the
person; relying on that they are (still) subscribed, I can waste time.

See the most recent mail I sent before this for details.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Alan McKinnon wrote:
> Judging by replies so far, I'd guess not many at all. You can't
> possibly know how many will or will not plonk someone. In the meantime
> Dale, I think you are projecting. Chill out brother, chill out. Plenty
> stuff in the world more deserving of attention than this. 

I fixed it now.  No more problems. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Tom Wijsman wrote:
> On Fri, 21 Mar 2014 12:41:03 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>> FYI.  Most people don't say anything, they just blacklist you.  After
>> that, you don't exist to them. 
> Yes, that's up to those few; it could happen, but most respond instead.

I just read the last message from you Tom. 

Good bye.

Dale

:-)  :-) 


-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 987 bytes --]

On Saturday 22 Mar 2014 00:28:04 Dale wrote:
> Alan McKinnon wrote:
> > Judging by replies so far, I'd guess not many at all. You can't
> > possibly know how many will or will not plonk someone. In the meantime
> > Dale, I think you are projecting. Chill out brother, chill out. Plenty
> > stuff in the world more deserving of attention than this.
> 
> I fixed it now.  No more problems.
> 
> Dale
> 
> :-)  :-)

Some of us read all, but reply only where we think we can add value and when 
time allows.

There is no need really on this list for verbal abuse, especially when a 
contributor has offered well considered advice and carefully articulated 
opinion.

Nevertheless, I also find personally addressed emails annoying, but it can be 
fixed by setting up a filter on most mail clients to drop them in the 
corresponding M/L.  This may be a more civil way than alienating people who 
want to join this community.  I'm just saying ...

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Mick wrote:
> On Saturday 22 Mar 2014 00:28:04 Dale wrote:
>> Alan McKinnon wrote:
>>> Judging by replies so far, I'd guess not many at all. You can't
>>> possibly know how many will or will not plonk someone. In the meantime
>>> Dale, I think you are projecting. Chill out brother, chill out. Plenty
>>> stuff in the world more deserving of attention than this.
>>
>> I fixed it now.  No more problems.
>>
>> Dale
>>
>> :-)  :-)
>
> Some of us read all, but reply only where we think we can add value
and when
> time allows.
>
> There is no need really on this list for verbal abuse, especially when a
> contributor has offered well considered advice and carefully articulated
> opinion.
>
> Nevertheless, I also find personally addressed emails annoying, but it
can be
> fixed by setting up a filter on most mail clients to drop them in the
> corresponding M/L.  This may be a more civil way than alienating
people who
> want to join this community.  I'm just saying ...
>

If a person sends html messages to this list, there is quite a few that
will block because they can't read them.  Same as with quite a few other
things that is not liked on this list.  Folks don't like html and don't
like getting two copies of the same message.  My point was and still is,
if he doesn't want to conform to what this list expects, he will be
blacklisted by people on this list.  Period.  It's nothing personal
about it since I would inform anyone else of the same thing.  It's
really that simple.

I still remember when I first joined this list.  I was told the same
thing about my email program sending html.  If I had not conformed to
the requests of people on  this mailing list, I would have been
blacklisted by a large group of people and was told that I would by some
of the very ones that would do it.  When joining a community, you
conform to what is expected.  You don't join and then force everyone
else to conform to what you want.  All Tom had to do is not CC
everyone.  Real simple.  No harder than me telling my software to send
text only message to gentoo.org.

It seemed to me that Tom refused the request of quite a few people even
after several asked him to change.  Based on that, I blacklisted him. 
That is something I rarely do but hey, it is what it is.  I fixed his
problem for him.  I suspect others have done the same.

BTW, I have yet to see him add much of anything to any discussion.  I've
seen his posts on -dev as well.   I won't now but still.  ;-)

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 3486 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 22/03/2014 01:46, Tom Wijsman wrote:
> On Sat, 22 Mar 2014 00:34:55 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> 2. A discussion forum. For these you do munge Reply-To: to be the list
>> so all discussion happens on-list and is visible to all
>>
>> gentoo-user has always been the latter and all discussion always takes
>> place on-list. If some doc somewhere says otherwise, change the doc to
>> reflect reality.
> 
> http://www.gentoo.org/main/en/lists.xml mentions it is about support
> too, and people that are here to be supported don't necessarily want to
> follow the discussion that comes along as well; thus unsubscribe
> before an answer or not subscribe at all in the first place, they then
> instead rely on receiving a mail regardless of that.
> 
> CC-ing ensures that the minutes spent on the answer make it reach the
> person; relying on that they are (still) subscribed, I can waste time.
> 
> See the most recent mail I sent before this for details.
> 


I disagree.

Your default position on things seems to be to favour the theoretical
position over the reality. I'm the opposite, being a sysadmin and not a
developer I'm a realist and not a theoretician. I work with the way
things are and really only look at the theory when stuff is proven broken.

What is currently happening is you are sending mails directly addressed
to me so they do not get filtered and end up cluttering my already full
inbox. You are breaking my filters.

I do not want to receive list mail from you addressed directly to me, I
want it addressed to the list.

I do want you to fix your mailer so that you stop inconveniencing me.
And I would *really* prefer not to have to tweak my filters to
accommodate you. I'd rather you do that heavy lifting (on account of you
causing it).

Do you see what I'm getting at?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Matti Nykyri]

On Mar 22, 2014, at 12:34, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 22/03/2014 01:46, Tom Wijsman wrote:
>> On Sat, 22 Mar 2014 00:34:55 +0200
>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>> 
>>> 2. A discussion forum. For these you do munge Reply-To: to be the list
>>> so all discussion happens on-list and is visible to all
>>> 
>>> gentoo-user has always been the latter and all discussion always takes
>>> place on-list. If some doc somewhere says otherwise, change the doc to
>>> reflect reality.
>> 
>> http://www.gentoo.org/main/en/lists.xml mentions it is about support
>> too, and people that are here to be supported don't necessarily want to
>> follow the discussion that comes along as well; thus unsubscribe
>> before an answer or not subscribe at all in the first place, they then
>> instead rely on receiving a mail regardless of that.
>> 
>> CC-ing ensures that the minutes spent on the answer make it reach the
>> person; relying on that they are (still) subscribed, I can waste time.
>> 
>> See the most recent mail I sent before this for details.
>> 
> 
> 
> I disagree.
> 
> Your default position on things seems to be to favour the theoretical
> position over the reality. I'm the opposite, being a sysadmin and not a
> developer I'm a realist and not a theoretician. I work with the way
> things are and really only look at the theory when stuff is proven broken.
> 
> What is currently happening is you are sending mails directly addressed
> to me so they do not get filtered and end up cluttering my already full
> inbox. You are breaking my filters.
> 
> I do not want to receive list mail from you addressed directly to me, I
> want it addressed to the list.
> 
> I do want you to fix your mailer so that you stop inconveniencing me.
> And I would *really* prefer not to have to tweak my filters to
> accommodate you. I'd rather you do that heavy lifting (on account of you
> causing it).
> 
> Do you see what I'm getting at?

I agree. I think it is arrogant to disturb lots of people that have done nothing to deserve it. People should be let to choose them self what they wanna do with their lives. If they wish to disengage some conversation, let them. Don't send them spam. The ones who wish to participate will stay on the list and the ones seeking for an answer can browse the archives.

Please respect other people.

-- 
-Matti 

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Matti Nykyri wrote:
> On Mar 22, 2014, at 12:34, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>
>> On 22/03/2014 01:46, Tom Wijsman wrote:
>>> On Sat, 22 Mar 2014 00:34:55 +0200
>>> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
>>>
>>>> 2. A discussion forum. For these you do munge Reply-To: to be the list
>>>> so all discussion happens on-list and is visible to all
>>>>
>>>> gentoo-user has always been the latter and all discussion always takes
>>>> place on-list. If some doc somewhere says otherwise, change the doc to
>>>> reflect reality.
>>> http://www.gentoo.org/main/en/lists.xml mentions it is about support
>>> too, and people that are here to be supported don't necessarily want to
>>> follow the discussion that comes along as well; thus unsubscribe
>>> before an answer or not subscribe at all in the first place, they then
>>> instead rely on receiving a mail regardless of that.
>>>
>>> CC-ing ensures that the minutes spent on the answer make it reach the
>>> person; relying on that they are (still) subscribed, I can waste time.
>>>
>>> See the most recent mail I sent before this for details.
>>>
>>
>> I disagree.
>>
>> Your default position on things seems to be to favour the theoretical
>> position over the reality. I'm the opposite, being a sysadmin and not a
>> developer I'm a realist and not a theoretician. I work with the way
>> things are and really only look at the theory when stuff is proven broken.
>>
>> What is currently happening is you are sending mails directly addressed
>> to me so they do not get filtered and end up cluttering my already full
>> inbox. You are breaking my filters.
>>
>> I do not want to receive list mail from you addressed directly to me, I
>> want it addressed to the list.
>>
>> I do want you to fix your mailer so that you stop inconveniencing me.
>> And I would *really* prefer not to have to tweak my filters to
>> accommodate you. I'd rather you do that heavy lifting (on account of you
>> causing it).
>>
>> Do you see what I'm getting at?
> I agree. I think it is arrogant to disturb lots of people that have done nothing to deserve it. People should be let to choose them self what they wanna do with their lives. If they wish to disengage some conversation, let them. Don't send them spam. The ones who wish to participate will stay on the list and the ones seeking for an answer can browse the archives.
>
> Please respect other people.
>

+1  to both Matti and Alan.  If he decides to change this and does, let
me know.  I'll consider removing the blacklist.  There is no need making
no telling how many people change their settings just because one person
refuses too. 

To the point about folks unsubscribing, if they do unsubscribe from the
list, it may be because they got what they want and do NOT want any more
messages.  I don't recall EVER sending a email to someone offlist unless
I was asked to or had to send some large attachement that the other
person wanted and I didn't want to send to the list.  If I unsubscribed
from this list, I would expect emails regarding this list to stop. 

At least I know now why folks told me what they did when I first
joined.  I'm just glad I wasn't so thick headed to not listen.  I
adjusted my settings and been here ever since.  < insert thumbs up here > 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 12:34:53 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> I disagree.

Can we agree to disagree?

> Your default position on things seems to be to favour the theoretical
> position over the reality. I'm the opposite, being a sysadmin and not
> a developer I'm a realist and not a theoretician. I work with the way
> things are and really only look at the theory when stuff is proven
> broken.

That I want my time to be spent useful is reality, not just theory;
until you can show me the invisible subscription state as well as the
Reply-To mungling are features, I keep my mailer fixed to unbreak that.

> What is currently happening is you are sending mails directly
> addressed to me so they do not get filtered and end up cluttering my
> already full inbox.

That is because you address me about this matter; if you weren't, I
wouldn't have sent you a single mail. Or perhaps one in a hundred days;
I consider the meta discussion brought up here to be more cluttering
than that uncertain single mail.

> You are breaking my filters.

Why do you filters allow list messages in your inbox?

> I do want you to fix your mailer so that you stop inconveniencing me.
> And I would *really* prefer not to have to tweak my filters to
> accommodate you. I'd rather you do that heavy lifting (on account of
> you causing it).

That list messages land in your inbox is caused by your filter and
mail client; as you can see per the example procmail rule, as well as
my mail client, neither of both do that here.

> Do you see what I'm getting at?

No; I don't see why I should stop following the mailing list etiquette,
start relying on possibly wasting time as well as break what is fixed.

But yes; for convenience, I've dropped you from CC.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 12:57:40 +0200
Matti Nykyri <matti.nykyri@iki.fi> wrote:

> I agree. I think it is arrogant to disturb lots of people that have
> done nothing to deserve it. People should be let to choose them self
> what they wanna do with their lives. If they wish to disengage some
> conversation, let them. Don't send them spam.

spam is send to a large number of recipients; I don't see how what is
discussing here is doing that, apart from extending this discussion.
It's not arrogant; it's a technical difference, which sets up different
approaches. That's why developers are requested to follow the etiquette.

> The ones who wish to participate will stay on the list and the ones
> seeking for an answer can browse the archives.

People that participate maybe are on the list and the ones seeking
for an answer might browse the archives. 

> Please respect other people.

Here's something that works for the both of us: Request someone to not
CC you in a follow-up mail when you catch them do it, they'll respect
that; that's a guarantee that we can be certain that you are subscribed.

That way; you respect that I want to spent my time to be guaranteed to
be useful, I respect that you don't want to be CC-ed in follow-up mails.

Similarly; if someone is off-list; it takes a single mail to keep me
from sending additional mails. As it clarifies a disengagement; that
unsubscribing is meant to be a disengagement, I can't find that rule...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 06:08:35 -0500
Dale <rdalek1967@gmail.com> wrote:

> To the point about folks unsubscribing, if they do unsubscribe from
> the list, it may be because they got what they want and do NOT want
> any more messages.

Or it may be because they are tired of the flow of mails, but yet they
are still awaiting a reply; the only respectful guarantee that works
for the both of us is if the user states a solution was found and/or
addresses me to send no further emails, that gives guarantees.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Sat, 22 Mar 2014 13:15:49 +0100, Tom Wijsman wrote:

> Here's something that works for the both of us: Request someone to not
> CC you in a follow-up mail when you catch them do it, they'll respect
> that; that's a guarantee that we can be certain that you are subscribed.

I tried that, you cc'd your response to me...

You are using Claws-Mail, it is easy to set up per-folder
configurations. I hit Reply, th reply goes to the list, I have to take
the specific step of using Reply to All to send you to copies of the
email.


-- 
Neil Bothwick

The road to HAL is paved with good intentions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 03/20/2014 06:42 PM, Tom Wijsman wrote:
> On Wed, 19 Feb 2014 10:19:43 +0000
> thegeezer <thegeezer@thegeezer.net> wrote:
>
>> the difficulty is that without knowing
> It is as easy as following the commits upstream makes, which is a
> short daily visit (or for less important followers, even weekly);
> that's really not too much asked for if you forked logind.
>
> It is even quite common practice and scriptable:
>
>     git fetch ... ; git log ... ; git diff ...
>
> In a similar way, I know Portage will get highlighting and a ^ indicator;
> without that being announced until release, here's a copy paste (note
> that what is above ^ would be colored in red, unwrapped to unbreak it):
>
> dev-lang/perl:0
>
>   (dev-lang/perl-5.18.2:0/5.18::gentoo, ebuild scheduled for merge) pulled in by
>     =dev-lang/perl-5.18* required by (virtual/perl-IO-1.280.0:0/0::gentoo, ebuild scheduled for merge)
>     ^              ^^^^^                                                                                                                                     
>
>   (dev-lang/perl-5.16.3:0/5.16::gentoo, installed) pulled in by
>     dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/IO-Socket-SSL-1.967.0:0/0::gentoo, installed)
>                  ^^^^^^^^                                                                                                                   
>     =dev-lang/perl-5.16* required by (virtual/perl-libnet-1.230.0:0/0::gentoo, installed)
>     ^              ^^^^^                                                                                                                        
>     (and 19 more with the same problems)
>
> And of course, that's not the only change happening; dependency
> resolution will become faster, some slot operator bug fixes happened
> but caused regressions in released versions and thus more of such fixes 
> will be done, some "no parents" messages during slot conflict output 
> were nuked, ...
>
> If I can type that as part of this mail, people could follow logind.
>

On 03/20/2014 06:42 PM, Tom Wijsman wrote:
> On Wed, 19 Feb 2014 10:19:43 +0000
> thegeezer <thegeezer@thegeezer.net> wrote:
>
>> the difficulty is that without knowing
> It is as easy as following the commits upstream makes, which is a
> short daily visit (or for less important followers, even weekly);
> that's really not too much asked for if you forked logind.
>
> It is even quite common practice and scriptable:
>
>     git fetch ... ; git log ... ; git diff ...
>
there's a slight misunderstanding here.
in a previous link on this list there was gnome developer that basically
said something like "we can't document everything that gnome uses in
systemd/logind because the developers are ahead of us, so in case of
difference the source code is correct".
gnome is big.  really big.
so you'd have to diff logind to check for new features and then diff
gnome to find how gnome is using those features.

so my point over 5 weeks ago was not about the difficulty in _finding_
the changes, but about keeping track of those changes and implementing htem.
if you read the rest of the thread you will see that in a whole i was
arguing that it is disingenuous to suggest that gnome does not require
logind.

if you don't see that perhaps you could volunteer to add logind api
features to openRC ?

btw, why did you reply to me cc the list instead of replying to list ?
i'm on the list already and so because of that my reply-to-list is broken.
it's easy enough to copy and paste the email address but please don't do
that again.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 03/22/2014 12:15 PM, Tom Wijsman wrote:
> That way; you respect that I want to spent my time to be guaranteed to
> be useful, I respect that you don't want to be CC-ed in follow-up
> mails. Similarly; if someone is off-list; it takes a single mail to
> keep me from sending additional mails. As it clarifies a
> disengagement; that unsubscribing is meant to be a disengagement, I
> can't find that rule... 
equally we all want our time spent to be guaranteed useful.
i've just gone through 40+ messages twice.
please stop CC'ing - just send it to the list.
if someone unsubscribes from the list and thus doesn't see their answer
there are other ways they can find it.  it is their issue if they do not
see the answer, it is easy enough to send an email to the list saying
"so long thanks for the fish, btw please send answers to x@y.com"

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[thegeezer]

On 03/22/2014 01:00 PM, thegeezer wrote:
> On 03/20/2014 06:42 PM, Tom Wijsman wrote:
>> On Wed, 19 Feb 2014 10:19:43 +0000
>> thegeezer <thegeezer@thegeezer.net> wrote:
>>
>>> the difficulty is that without knowing
>> It is as easy as following the commits upstream makes, which is a
>> short daily visit (or for less important followers, even weekly);
>> that's really not too much asked for if you forked logind.
>>
>> It is even quite common practice and scriptable:
>>
>>     git fetch ... ; git log ... ; git diff ...
>>
>> In a similar way, I know Portage will get highlighting and a ^ indicator;
>> without that being announced until release, here's a copy paste (note
>> that what is above ^ would be colored in red, unwrapped to unbreak it):
>>
>> dev-lang/perl:0
>>
>>   (dev-lang/perl-5.18.2:0/5.18::gentoo, ebuild scheduled for merge) pulled in by
>>     =dev-lang/perl-5.18* required by (virtual/perl-IO-1.280.0:0/0::gentoo, ebuild scheduled for merge)
>>     ^              ^^^^^                                                                                                                                     
>>
>>   (dev-lang/perl-5.16.3:0/5.16::gentoo, installed) pulled in by
>>     dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/IO-Socket-SSL-1.967.0:0/0::gentoo, installed)
>>                  ^^^^^^^^                                                                                                                   
>>     =dev-lang/perl-5.16* required by (virtual/perl-libnet-1.230.0:0/0::gentoo, installed)
>>     ^              ^^^^^                                                                                                                        
>>     (and 19 more with the same problems)
>>
>> And of course, that's not the only change happening; dependency
>> resolution will become faster, some slot operator bug fixes happened
>> but caused regressions in released versions and thus more of such fixes 
>> will be done, some "no parents" messages during slot conflict output 
>> were nuked, ...
>>
>> If I can type that as part of this mail, people could follow logind.
>>
> On 03/20/2014 06:42 PM, Tom Wijsman wrote:
>> On Wed, 19 Feb 2014 10:19:43 +0000
>> thegeezer <thegeezer@thegeezer.net> wrote:
>>
>>> the difficulty is that without knowing
>> It is as easy as following the commits upstream makes, which is a
>> short daily visit (or for less important followers, even weekly);
>> that's really not too much asked for if you forked logind.
>>
>> It is even quite common practice and scriptable:
>>
>>     git fetch ... ; git log ... ; git diff ...
>>
> there's a slight misunderstanding here.
> in a previous link on this list there was gnome developer that basically
> said something like "we can't document everything that gnome uses in
> systemd/logind because the developers are ahead of us, so in case of
> difference the source code is correct".
> gnome is big.  really big.
> so you'd have to diff logind to check for new features and then diff
> gnome to find how gnome is using those features.
>
> so my point over 5 weeks ago was not about the difficulty in _finding_
> the changes, but about keeping track of those changes and implementing htem.
> if you read the rest of the thread you will see that in a whole i was
> arguing that it is disingenuous to suggest that gnome does not require
> logind.
>
> if you don't see that perhaps you could volunteer to add logind api
> features to openRC ?
>
> btw, why did you reply to me cc the list instead of replying to list ?
> i'm on the list already and so because of that my reply-to-list is broken.
> it's easy enough to copy and paste the email address but please don't do
> that again.
>
>
sorry for the double length and content email. an accident with the copy
and paste.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tanstaafl]

On 3/21/2014 5:57 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> How does one send email to*THIS*  list, without being subscribed in
> the first place?  A bugzilla mailing list is a different matter.

I think that is the main and primary point.

I loathe lists that allow posts from non subscribers (<spit>libreoffice 
users</spit>), because it creates this exact problem.

But in those cases, it should be on those who wish to leech (ask 
questions/get help from the list without having to subscribe) to 
proactively get their answers, by reading the archives on the web, etc.

The burden absolutely should NEVER be on the list participants to try to 
figure out who needs to be individually CC'd on replies and who doesn't.

Of course, if someone asks a question on such a list, and they 
specifically mention they are not subscribed and ask to be directly 
CC'd, then that is the one case when doing so is ok. But to blindly do 
this to everyone on the list just to insure that your oh-so-valuable 
reply makes it to the OP is just the height of arrogance and conceit.

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 13:00:59 +0000
thegeezer <thegeezer@thegeezer.net> wrote:

> [...] so my point over 5 weeks ago was not about the difficulty in
> _finding_ the changes,

Ah, thanks; I see.

> but about keeping track of those changes and implementing htem.

Here, I would agree with if you have a lot of other things to do; I
don't see this as a problem though for someone whom puts time apart to
do such a fork, keeping track is as easy as following two git logs.
Granted, understanding and implementing the changes is another story,
in which I again agree with you; I just wanted to point out they're not
hidden, they're just not announced, but it appears we agree on that.

> if you read the rest of the thread you will see that in a whole i was
> arguing that it is disingenuous to suggest that gnome does not
> require logind.

There is indeed an URL brought up early on, with which I agree with:

https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

There's also a more recent post that I think hasn't been brought up:

https://blogs.gnome.org/ovitters/2014/02/03/my-thoughts-on-the-default-init-system-for-debian-discussion

> if you don't see that perhaps you could volunteer to add logind api
> features to openRC ?

Well, I wish I could accomplish all these things; but I have other work
that I'm committing myself to, I've been thinking about a proof of
concept to point out it is possible but I haven't had the time to do it.

My past commits were spent on bringing MATE to the Portage tree; if I
would work on a logind implementation, there wouldn't be MATE.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Sat, 22 Mar 2014 12:56:17 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Sat, 22 Mar 2014 13:15:49 +0100, Tom Wijsman wrote:
> 
> > Here's something that works for the both of us: Request someone to
> > not CC you in a follow-up mail when you catch them do it, they'll
> > respect that; that's a guarantee that we can be certain that you
> > are subscribed.
> 
> I tried that, you cc'd your response to me...

Well, it is new; this response has no CC.

> You are using Claws-Mail, it is easy to set up per-folder
> configurations. I hit Reply, th reply goes to the list, I have to take
> the specific step of using Reply to All to send you to copies of the
> email.

How to set this up per folder?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 09:35:50 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 3/21/2014 5:57 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> > How does one send email to*THIS*  list, without being subscribed in
> > the first place?  A bugzilla mailing list is a different matter.
> 
> I think that is the main and primary point.
> 
> I loathe lists that allow posts from non subscribers
> (<spit>libreoffice users</spit>), because it creates this exact
> problem.

We could fix *THIS* list to not allow that to exist; given that change,
I'm fine with dropping CC on every mail on *THIS* list. Furthermore,
I've asked in another mail how to set this per folder in my mail
client; which should allow me to conform to the wishes of a list.

> But in those cases, it should be on those who wish to leech (ask 
> questions/get help from the list without having to subscribe) to 
> proactively get their answers, by reading the archives on the web,
> etc.

People participate in more than just this list; at that point, there's
a lot to check up with. It creates an information overflow; or
rather, too much to check up on. This is why notifications were
invented on various new and modern websites; though, given that mailing
list archives date from a while ago, such notifications are not yet
present on such services. Up to a point that the user is unaware of
that; even when using the web form where they had to fill in their
mail, 'cause why did they have to fill in their mail there anyway? 

> The burden absolutely should NEVER be on the list participants to try
> to figure out who needs to be individually CC'd on replies and who
> doesn't.

But given the technical difficulties, there is such a burden on us;
that's why it is part of the mailing list etiquette that I follow and
are requested to follow by other Gentoo developers.

> Of course, if someone asks a question on such a list, and they 
> specifically mention they are not subscribed and ask to be directly 
> CC'd, then that is the one case when doing so is ok.

If they are aware; but see my response to leeching, are they aware?

> But to blindly do this to everyone on the list just to insure that
> your oh-so-valuable reply makes it to the OP is just the height of
> arrogance and conceit.

This isn't done blindly; I check up the rules and FAQ prior to do doing
it, as well as listen to participants that warn me early. In this case,
for the Gentoo mailing lists, the mailing list etiquette was brought to
my attention and therefore I have been CC-ing for hundreds of e-mails
without any remarks (and most people just repsond), to be surprised
that a whole discussion about it is started here. It isn't arrogance or
conceit; rather, it is being consistent and following etiquette.

You should note that the early part of this discussion is based on one
or two individuals that appear as inconsistent; however, given there
are more people that voice this now, _I am concerned_ to change it
specifically for those who request it and we could solve the technical
difficulty by reducing the problem by requesting off-list replies to be
disallowed and/or adapting the mail to new subscribers to mention that
if they want to be CC-ed that they should explicitly mention that.

Yes, I am inconsistent with *THIS* mailing list; let's change things to
make such inconsistency unnecessary, to fix this forever and always.

Otherwise we'll continue to get responses like these

http://article.gmane.org/gmane.linux.gentoo.user/273297

while we could just make those "do not ..." no longer necessary.

Sorry for the hassle and thanks for the understanding.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[luis jure]

el 2014-03-22 a las 15:50 Tom Wijsman escribió:

> How to set this up per folder?
 
rigth-click on the folder, "Properties..." -> "Compose" -> "default to:"

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 12:28:25 -0300
luis jure <ljc@internet.com.uy> wrote:

> 
> el 2014-03-22 a las 15:50 Tom Wijsman escribió:
> 
> > How to set this up per folder?
>  
> rigth-click on the folder, "Properties..." -> "Compose" -> "default
> to:"

Thank you very much +1; I see some other features there too that can be
handy, eg. subject RegExp simplification.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Tom Wijsman]

On Sat, 22 Mar 2014 16:38:54 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sat, 22 Mar 2014 12:28:25 -0300
> luis jure <ljc@internet.com.uy> wrote:
> 
> > 
> > el 2014-03-22 a las 15:50 Tom Wijsman escribió:
> > 
> > > How to set this up per folder?
> >  
> > rigth-click on the folder, "Properties..." -> "Compose" -> "default
> > to:"
> 
> Thank you very much +1; I see some other features there too that can
> be handy, eg. subject RegExp simplification.

Okay, the CCs have been removed; to anyone else wondering how to do,
you can tick the box of the field (here: CC) you want to drop and then
leave the textbox empty, that way clicking on "All" will not CC people.

Now I really hope the amount of people not aware of replies is small...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Dale]

Tanstaafl wrote:
> On 3/21/2014 5:57 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> How does one send email to*THIS*  list, without being subscribed in
>> the first place?  A bugzilla mailing list is a different matter.
>
> I think that is the main and primary point.
>
> I loathe lists that allow posts from non subscribers
> (<spit>libreoffice users</spit>), because it creates this exact problem.
>
> But in those cases, it should be on those who wish to leech (ask
> questions/get help from the list without having to subscribe) to
> proactively get their answers, by reading the archives on the web, etc.
>
> The burden absolutely should NEVER be on the list participants to try
> to figure out who needs to be individually CC'd on replies and who
> doesn't.
>
> Of course, if someone asks a question on such a list, and they
> specifically mention they are not subscribed and ask to be directly
> CC'd, then that is the one case when doing so is ok. But to blindly do
> this to everyone on the list just to insure that your oh-so-valuable
> reply makes it to the OP is just the height of arrogance and conceit.
>
>


Exactly.  I been on this list about a decade now.  In that time, I have
seen maybe a handful of people that requested a CC.  I seem to vaguely
recall one that couldn't access his regular email program, using
different computer or something I guess, and didn't want to subscribe
with the email addy he was currently using.  The folks that were helping
him did CC him since in that case, he needed it.  That was a really long
time ago.  In recent history tho, I don't recall anyone requesting a CC
at all.  If they did, it was on a thread that I did not read.  I usually
at least try to read the first post to see if I can be of help. 

It seems that after burning a few bridges tho, this one finally
understood the point.  Time will tell I guess.

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On Sat, 22 Mar 2014 16:52:56 +0100, Tom Wijsman wrote:

> > Thank you very much +1; I see some other features there too that can
> > be handy, eg. subject RegExp simplification.  
> 
> Okay, the CCs have been removed; to anyone else wondering how to do,
> you can tick the box of the field (here: CC) you want to drop and then
> leave the textbox empty, that way clicking on "All" will not CC people.
> 
> Now I really hope the amount of people not aware of replies is small...

If they do, it's their fault. Posting a question to this list and not
bothering to wait for a response is just plain rude, especially when
people go to the trouble of trying to help.

I'm not saying that is how all lists work, on some the CC makes sense,
but this list isn't like that, so thank you for recognising it and
conforming to the accepted behaviour.


-- 
Neil Bothwick

"I teleported home one night
With Ron and Sid and Meg.
Ron stole Meggie's heart away
And I got Sidney's leg."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 21/03/14, Tom Wijsman wrote:
> On Fri, 21 Mar 2014 07:10:49 -0500
> Dale <rdalek1967@gmail.com> wrote:
> 
> > So let's get this straight.  You want most everyone on this list to
> > change what they have to do to remove dups caused by you, instead of
> > you changing what you do to fix the problem?
> 
> Everyone else is okay with it, as only one in a thousand speaks up
> about it; the problem rather is with that 0.1% than that it is with me,
> as I just use mailing lists as they are supposed to be used.

Yes.

I want to be cc'ed on threads I'm involved in. That's just how it should
be done and what almost everybody expects on technical mailing lists.

-- 
Nicolas Sebrecht

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 21/03/14, Dale wrote:
> Tom Wijsman wrote:
> > On Fri, 21 Mar 2014 12:41:03 -0500
> > Dale <rdalek1967@gmail.com> wrote:
> >
> >> FYI.  Most people don't say anything, they just blacklist you.  After
> >> that, you don't exist to them. 
> > Yes, that's up to those few; it could happen, but most respond instead.
> 
> I just read the last message from you Tom. 
> 
> Good bye.

Heh. Blacklisting just make things even worse because you won't
blacklist other contributors responding to Tom. So, you'll have broken
and partial threads.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, March 25, 2014 16:35, Nicolas Sebrecht wrote:
> The 21/03/14, Tom Wijsman wrote:
>> On Fri, 21 Mar 2014 07:10:49 -0500
>> Dale <rdalek1967@gmail.com> wrote:
>>
>> > So let's get this straight.  You want most everyone on this list to
>> > change what they have to do to remove dups caused by you, instead of
>> > you changing what you do to fix the problem?
>>
>> Everyone else is okay with it, as only one in a thousand speaks up
>> about it; the problem rather is with that 0.1% than that it is with me,
>> as I just use mailing lists as they are supposed to be used.
>
> Yes.
>
> I want to be cc'ed on threads I'm involved in. That's just how it should
> be done and what almost everybody expects on technical mailing lists.

Nicolas,

It has already been determined that on this list we do not want extra CCs,

Please respect that and don't reopen this discussion.

--
Joost

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[»Q«]

On Fri, 21 Mar 2014 06:37:20 -0400
Tanstaafl <tanstaafl@libertytrek.org> wrote:

> On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
> > Why should Gentoo have a default?
> 
> Defaults are always a good idea - as long as they are reasonable and 
> rational.

In that case, Gentoo is missing a lot of "good" things, from a default
system logger to a default desktop environment.

AFAICS, the benefit of defaults, provided they're reasonable, is that
they remove the burden of making choices from the user.  But I keep
reading that Gentoo is all about user choice.

> > ISTM the only good reason is that not having a default would make
> > the documentation a lot more complicated.
> 
> Documentation, *and* the install process itself.

I'm not seeing that at all.

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 25/03/2014 22:08, »Q« wrote:
> On Fri, 21 Mar 2014 06:37:20 -0400
> Tanstaafl <tanstaafl@libertytrek.org> wrote:
> 
>> On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
>>> Why should Gentoo have a default?
>>
>> Defaults are always a good idea - as long as they are reasonable and 
>> rational.
> 
> In that case, Gentoo is missing a lot of "good" things, from a default
> system logger to a default desktop environment.
> 
> AFAICS, the benefit of defaults, provided they're reasonable, is that
> they remove the burden of making choices from the user.  But I keep
> reading that Gentoo is all about user choice.

You are conflating two things, it's actually quite disingenuous.

Gentoo provides choice so you can do what you want. That doesn't
preclude providing a default that suits people who see no need to make
*that* choice for *them*, particularly when the thing being chosen is
necessary or almost so.

> 
>>> ISTM the only good reason is that not having a default would make
>>> the documentation a lot more complicated.
>>
>> Documentation, *and* the install process itself.
> 
> I'm not seeing that at all.

You have to have *something* to be pid 1. the stage 3 might as well
provide one of those somethings that suits the common case

You can make it /bin/bash if you want, but that would be a very niche
usage. The large majority of new installs will want a conventional init
system whether SysVinit-based or systemd based. Traditionally SysVinit
was the only real contender and baselayout/openerc were originally
written for Gentoo. So those are still the defaults.

Without a default, the user must set one up manually for things to work
at all on first reboot. The install docs try hard to get the user
through the necessary steps to get a bootable system, a lot of effort
went into making the steps to accomplish that fewer, no more


-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[»Q«]

On Wed, 26 Mar 2014 00:25:26 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 25/03/2014 22:08, »Q« wrote:
> > On Fri, 21 Mar 2014 06:37:20 -0400
> > Tanstaafl <tanstaafl@libertytrek.org> wrote:
> > 
> >> On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
> >>> Why should Gentoo have a default?
> >>
> >> Defaults are always a good idea - as long as they are reasonable
> >> and rational.
> > 
> > In that case, Gentoo is missing a lot of "good" things, from a
> > default system logger to a default desktop environment.
> > 
> > AFAICS, the benefit of defaults, provided they're reasonable, is
> > that they remove the burden of making choices from the user.  But I
> > keep reading that Gentoo is all about user choice.
> 
> You are conflating two things, it's actually quite disingenuous.
> 
> Gentoo provides choice so you can do what you want. That doesn't
> preclude providing a default that suits people who see no need to make
> *that* choice for *them*, particularly when the thing being chosen is
> necessary or almost so.

Of course it doesn't preclude that;  I'm sorry if implied that it did.

> >>> ISTM the only good reason is that not having a default would make
> >>> the documentation a lot more complicated.
> >>
> >> Documentation, *and* the install process itself.
> > 
> > I'm not seeing that at all.
> 
> You have to have *something* to be pid 1. the stage 3 might as well
> provide one of those somethings that suits the common case
> 
> You can make it /bin/bash if you want, but that would be a very niche
> usage. The large majority of new installs will want a conventional
> init system whether SysVinit-based or systemd based. Traditionally
> SysVinit was the only real contender and baselayout/openerc were
> originally written for Gentoo. So those are still the defaults.
> 
> Without a default, the user must set one up manually for things to
> work at all on first reboot. The install docs try hard to get the user
> through the necessary steps to get a bootable system, a lot of effort
> went into making the steps to accomplish that fewer, no more

Requiring the fewest possible number of choices to get to a bootable
system is a much better argument for a default than "defaults are
always good".

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Alan McKinnon]

On 26/03/2014 01:34, »Q« wrote:
> On Wed, 26 Mar 2014 00:25:26 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> On 25/03/2014 22:08, »Q« wrote:
>>> On Fri, 21 Mar 2014 06:37:20 -0400
>>> Tanstaafl <tanstaafl@libertytrek.org> wrote:
>>>
>>>> On 3/20/2014 5:48 PM, »Q« <boxcars@gmx.net> wrote:
>>>>> Why should Gentoo have a default?
>>>>
>>>> Defaults are always a good idea - as long as they are reasonable
>>>> and rational.
>>>
>>> In that case, Gentoo is missing a lot of "good" things, from a
>>> default system logger to a default desktop environment.
>>>
>>> AFAICS, the benefit of defaults, provided they're reasonable, is
>>> that they remove the burden of making choices from the user.  But I
>>> keep reading that Gentoo is all about user choice.
>>
>> You are conflating two things, it's actually quite disingenuous.
>>
>> Gentoo provides choice so you can do what you want. That doesn't
>> preclude providing a default that suits people who see no need to make
>> *that* choice for *them*, particularly when the thing being chosen is
>> necessary or almost so.
> 
> Of course it doesn't preclude that;  I'm sorry if implied that it did.
> 
>>>>> ISTM the only good reason is that not having a default would make
>>>>> the documentation a lot more complicated.
>>>>
>>>> Documentation, *and* the install process itself.
>>>
>>> I'm not seeing that at all.
>>
>> You have to have *something* to be pid 1. the stage 3 might as well
>> provide one of those somethings that suits the common case
>>
>> You can make it /bin/bash if you want, but that would be a very niche
>> usage. The large majority of new installs will want a conventional
>> init system whether SysVinit-based or systemd based. Traditionally
>> SysVinit was the only real contender and baselayout/openerc were
>> originally written for Gentoo. So those are still the defaults.
>>
>> Without a default, the user must set one up manually for things to
>> work at all on first reboot. The install docs try hard to get the user
>> through the necessary steps to get a bootable system, a lot of effort
>> went into making the steps to accomplish that fewer, no more
> 
> Requiring the fewest possible number of choices to get to a bootable
> system is a much better argument for a default than "defaults are
> always good".


Yes, defaults make the most sense when you have virtuals, or when you
must have 1 thing out of a range of things.




-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Nicolas Sebrecht]

The 25/03/14, J. Roeleveld wrote:

> It has already been determined that on this list we do not want extra CCs,

I think you have determined this on your side (I'm not doing a personal
attack, "you" is not "you" alone).

> Please respect that and don't reopen this discussion.

Please don't tell us what we should do in the first place. You
(including some others here) seem well comfortable with the idea of
making Gentoo's mailing lists an exception with the glitchy way everyone
is supposed to work with mails here.

cc'ing is a mark of respect in accordance with both the technical norme
and the persons involved in a discussion. You won't remove this from my
education and local policies instored by legitimate (or not)
policymakers won't change my practice and expectation.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie

[Mark David Dumlao]

On Wed, Mar 26, 2014 at 4:49 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
>
> The 25/03/14, J. Roeleveld wrote:
>
> > It has already been determined that on this list we do not want extra CCs,
>
> I think you have determined this on your side (I'm not doing a personal
> attack, "you" is not "you" alone).
>

What usually happens in the gentoo users mailing list is that a bunch
of old fogies get set in their ways and project their preferences onto
everybody else. Just that they're the noisiest old fogies - the vast
majority of mailing list members probably just subscribe to listen for
potential gotchas in their installs / upgrades and never chime in on
matters of opinion, in part because of how mean the list can be. I
wouldn't be surprised if most users really just don't give an awk
about this discussion for or against.

I've never seen the extra cc nonsense written or even remotely hinted
at anywhere except by a handful of whiners, so I don't think it's the
majority opinion and neither should you.
-- 
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none