Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Pacho Ramos]

El mar, 28-10-2014 a las 17:05 +0100, Lennart Poettering escribió:
[...]
> http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html

Looks interesting. Have you think in having some kind of wiki or page
listing this kind of "tricks" to solve things like that. That way we
prevent people from applying many different solutions that could have
different drawbacks and also have them in a place a bit more easily
accessible

Thanks a lot


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 28, 2014 at 05:16:38PM +0100, Jan Alexander Steffens wrote:
> On Oct 28, 2014 5:05 PM, "Lennart Poettering" 
> wrote:
> > On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote:
> > > That is not entirely true.  I'm a user (because systemd is in Fedora
> > > 19), and I've complained that if I mark an /etc/fstab entry as
> > > "nofail", some part of systemd will wait *forever* to see if the
> > > partition becomes available, whereas the behavior that I want (which
> > > was provided in earlier Fedora releases) is that once the system
> > > gets to the point of user logins, it will give up on automatic booting
> > > (and leave it to manual control).
> >
> > I have already replied to this, and pointed out that such a scheme is
> > inherently racy, and that this is something we will unlikely support
> > natively in systemd. Sorry for that.
> 
> I think the actual issue here is the behavior of Type=idle, which delays
> the gettys for an annoying amount of time.
> 
> Maybe launching the getty should shut off boot messages instead. Or maybe
> this should happen after a configurable IdleTimeout instead of having
> Type=idle always wait until end of transaction.
You mean like the code in execute.c does?

#define IDLE_TIMEOUT_USEC (5*USEC_PER_SEC)
...
r = fd_wait_for_event(idle_pipe[0], POLLHUP, IDLE_TIMEOUT_USEC);

if (idle_pipe[3] >= 0 && r == 0 /* timeout */) {
  /* Signal systemd that we are bored and want to continue. */

;)

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jan Alexander Steffens]

On Oct 28, 2014 5:05 PM, "Lennart Poettering" 
wrote:
> On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote:
> > That is not entirely true.  I'm a user (because systemd is in Fedora
> > 19), and I've complained that if I mark an /etc/fstab entry as
> > "nofail", some part of systemd will wait *forever* to see if the
> > partition becomes available, whereas the behavior that I want (which
> > was provided in earlier Fedora releases) is that once the system
> > gets to the point of user logins, it will give up on automatic booting
> > (and leave it to manual control).
>
> I have already replied to this, and pointed out that such a scheme is
> inherently racy, and that this is something we will unlikely support
> natively in systemd. Sorry for that.

I think the actual issue here is the behavior of Type=idle, which delays
the gettys for an annoying amount of time.

Maybe launching the getty should shut off boot messages instead. Or maybe
this should happen after a configurable IdleTimeout instead of having
Type=idle always wait until end of transaction.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 28.10.14 11:28, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > From: Zbigniew Jędrzejewski-Szmek 
> > 
> > That mostly applies to people who actually don't use systemd and are
> > commenting from the peanut gallery. Actual *users* when they are unhappy
> > are unhappy about bugs.
> 
> That is not entirely true.  I'm a user (because systemd is in Fedora
> 19), and I've complained that if I mark an /etc/fstab entry as
> "nofail", some part of systemd will wait *forever* to see if the
> partition becomes available, whereas the behavior that I want (which
> was provided in earlier Fedora releases) is that once the system
> gets to the point of user logins, it will give up on automatic booting
> (and leave it to manual control).

I have already replied to this, and pointed out that such a scheme is
inherently racy, and that this is something we will unlikely support
natively in systemd. Sorry for that. 

And please don't make this a "but it worked fine in sysvinit!" thing,
because it was racy there as well.

> I've not received any useful feedback on how to customize my system to
> behave that way, and no indication that there is any intention to add
> it as a feature.

http://lists.freedesktop.org/archives/systemd-devel/2014-October/024325.html

I am sorry, if this reply doesn't make you happy, but I guess we will
not be able to mke everybody happy. But please be fair enough to admit
that you did get a response from us, and a clear explanation that we
will not support this upstream, and why we won't do so.

> So it is clear that this is not a "bug", as it is the behavior
> intended by the designers, but I'm still not happy.

I am sorry for that, 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Daniele Nicolodi]

On 28/10/14 16:28, Dale R. Worley wrote:
>> From: Zbigniew Jędrzejewski-Szmek 
>>
>> That mostly applies to people who actually don't use systemd and are
>> commenting from the peanut gallery. Actual *users* when they are unhappy
>> are unhappy about bugs.
> 
> That is not entirely true.  I'm a user (because systemd is in Fedora
> 19), and I've complained that if I mark an /etc/fstab entry as
> "nofail", some part of systemd will wait *forever* to see if the
> partition becomes available, whereas the behavior that I want (which
> was provided in earlier Fedora releases) is that once the system
> gets to the point of user logins, it will give up on automatic booting
> (and leave it to manual control).
> 
> I've not received any useful feedback on how to customize my system to
> behave that way, and no indication that there is any intention to add
> it as a feature.
> 
> So it is clear that this is not a "bug", as it is the behavior
> intended by the designers, but I'm still not happy.

What you write above is not entirely true either:

On 22/10/14 20:55, Lennart Poettering wrote:> On Fri, 12.09.14 15:25,
Dale R. Worley (wor...@alum.mit.edu) wrote:
>
>>> From: Tobias Geerinckx-Rice 
>>
>>> Step back, and define exactly what it is you actually need^Wwant to do.
>>
>> For a certain entry in /etc/fstab (which will in practice always have
>> the option "nofail"), if the device is not available "until booting is
>> over" (which I'm willing to denote with a specified period of time),
>> after that, it will not be automatically mounted if it becomes
>> available.
>
> This is currently not available, and it sounds very special and racy
> to support it upstream I think. Sorry!
>
> If you want to hack something up like this, I'd recommend writing a
> timer unit/cronjob that creates a file $PATH after $SECONDS after
boot. Then, add
> a drop-in file to /etc/systemd/system/$MOUNTUNIT.d/foobar.conf, and
> write into it:
>
> [Unit]
> ConditionFileExists=!/the/file/you/create
>
> That way the mount unit will always be queued, but will actually be
> conditionalized out $SECONDS after boot, if you follow what I mean.
>
> Hope this is helpful.
>
> Lennart

Cheers,
Daniele
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: Zbigniew Jędrzejewski-Szmek 
> 
> That mostly applies to people who actually don't use systemd and are
> commenting from the peanut gallery. Actual *users* when they are unhappy
> are unhappy about bugs.

That is not entirely true.  I'm a user (because systemd is in Fedora
19), and I've complained that if I mark an /etc/fstab entry as
"nofail", some part of systemd will wait *forever* to see if the
partition becomes available, whereas the behavior that I want (which
was provided in earlier Fedora releases) is that once the system
gets to the point of user logins, it will give up on automatic booting
(and leave it to manual control).

I've not received any useful feedback on how to customize my system to
behave that way, and no indication that there is any intention to add
it as a feature.

So it is clear that this is not a "bug", as it is the behavior
intended by the designers, but I'm still not happy.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 27, 2014 at 06:25:56PM -0400, Dale R. Worley wrote:
> > From: "Lennart Poettering" 
> > 
> > Please, let's discuss this elsewhere. Let's keep a strict technical
> > focus on this ML!
> 
> I believe that you mean that outsiders are welcome here to provide
> assistance to systemd as it has already been implemented.  One
> difficulty is that outsiders are usually not able to provide such
> assistance.
No really, people do feature requests here and on the bug trackers all
the time [1].

Nevertheless, systemd is a low level compenent, and not really
directed at *users* as such, more at os developers, packagers, etc.
So the distinction between "development" and "use" is not clearly
cut. Questions and bug reports often lead directly to changes in
the codebase. Creating a split into two lists would only slow
things down here.

Creating a separate systemd-users list was discussed, but who would
answers the questions there? If you expect the developers do it,
then there isn't much difference than simply answering those questions
on -devel. If you expect other people to do it, then wiki style
distribution-specific documentation is better in the long run,
since systemd is a fast moving target and the best practice often
changes over time.

What I think you're really thinking about is "systemd-advocy" to
discuss lofty ideals and deep motivaitions. But nobody has time for
that ;)

[1] 
https://bugs.freedesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=general&known_name=systemd%20RFEs&list_id=485720&product=systemd&query_based_on=systemd%20RFEs&query_format=advanced&resolution=---&short_desc=^RFE&short_desc_type=regexp

> It would be useful if there was a mailing list where outsiders could
> come with problems -- "systemd does not implement what I need as it is
> provided by the distro".  I would expect such a mailing list to be
> named "systemd-users".  But no such list seems to exist.  (And thus,
> they show up in systemd-devel.)
> 
> This leaves users with the sense that they are expected to use systemd
> as it is provided, and it makes it hard for them to customize systems
> that do what they need.  This reminds them of Microsoft products and
> makes them unhappy.
That mostly applies to people who actually don't use systemd and are
commenting from the peanut gallery. Actual *users* when they are unhappy
are unhappy about bugs.

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Mon, 27.10.14 18:25, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > From: "Lennart Poettering" 
> > 
> > Please, let's discuss this elsewhere. Let's keep a strict technical
> > focus on this ML!
> 
> I believe that you mean that outsiders are welcome here to provide
> assistance to systemd as it has already been implemented.  One
> difficulty is that outsiders are usually not able to provide such
> assistance.
> 
> It would be useful if there was a mailing list where outsiders could
> come with problems -- "systemd does not implement what I need as it is
> provided by the distro".  I would expect such a mailing list to be
> named "systemd-users".  But no such list seems to exist.  (And thus,
> they show up in systemd-devel.)

Well, systemd is a suite of components that people build OSes from. As
such it isn't really an app you install on top of your OS, it's more a
toolset for distro and device builders. Now, if end users have
questions about details how they can uses these devices and distros,
then I figure they should always contact the manufacturers of these
devices, and the distro developers first.

Or in other words: we are not the final product that people should
interface with, we just provide a set of components where other people
can build final products out, and by doing so they also need to take
the responsibility for providing a first level of help for it.

Now, of course, the more technical things get, sometimes its better to
ask upstream, and we currently do not have a separate ML for questions
like that, we use systemd-devel for that, which of course is primarily
used for development. But I think it's still OK that way, as the
amount of technical user question we get is still managable, and by
not making the distinction between the group of developers and the
group of users too strict I guess our community can only win.

systemd-devel is the place for *technical* discussions only though. If
you have a technical point to make, a technical question to ask, a
patch to send, a technical suggestion to make, a technical feature
request to post, it's the right place.

However, it's not the place for UNIX philosophy discussions, about
discussions what we should be and what we shouldn't be. Now we could
open a new ML for that philosphical kind of stuff, but I have serious
doubts that many of us developers would subscribe there, hence I think
it would be better to do those discussions elsewhere, maybe on blogs,
g+ posts, on twitter, on lwn, on reddit... The discussions are being
had there anyway, and that's OK that way. Some of the systemd
developers scan and post on these forums anyway[1], regularly, hence I
really don't see the need for a new ML.

Lennart

[1] I scan and sometimes post on LWN. I think Tom does the same on g+
and lwn. Daniel on twitter, and so on...

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: "Lennart Poettering" 
> 
> Please, let's discuss this elsewhere. Let's keep a strict technical
> focus on this ML!

I believe that you mean that outsiders are welcome here to provide
assistance to systemd as it has already been implemented.  One
difficulty is that outsiders are usually not able to provide such
assistance.

It would be useful if there was a mailing list where outsiders could
come with problems -- "systemd does not implement what I need as it is
provided by the distro".  I would expect such a mailing list to be
named "systemd-users".  But no such list seems to exist.  (And thus,
they show up in systemd-devel.)

This leaves users with the sense that they are expected to use systemd
as it is provided, and it makes it hard for them to customize systems
that do what they need.  This reminds them of Microsoft products and
makes them unhappy.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Wed, 22.10.14 15:54, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > From: Lennart Poettering 
> 
> > We are always interested in technical feedback. 
> > 
> > We are not very interested in FUD mails that tell us how we'd "force"
> > people, how we'd behave like microsoft and so on. That's not useful,
> > that's pretty much only hurtful. 
> 
> I haven't read this full thread, and it probably isn't useful for me
> to do so.  But it seems that the first question to be answered by the
> developers is:
> 
>   Are they concerned that uptake is not as fast as they'd like?

No. We are not concerned. Within three years all most major distros opted
for systemd as default. That's way more and way quicker than what we
could ever hope for.

> and if the answer to that is Yes, then:
> 
>   Would they like to hear feedback from users as to what they
>   might do about it?

Yes, we always ask for good feedback. Much of what systemd is today is
the result of getting and incorporating feedback. 

However, we are not really interested in constantly repeated claims of
"forcing" and "being like microsoft", because that's neither original,
nor true, nor interesting, nor technical, nor relevant.

Also, note that while we care a lot for useful feedback we will not
implement everything people ask for, and even deny patches. Saying
"no" to patches and suggestions is necessary to keep the project on
track. We will continue to do so. If figure by average though, we
probably implement two suggestions we got through feedback for every
one suggestion we refuse. And if we say "no" to a suggestion or patch
you'll at least get an explanation why.

hence, please keep the feedback coming, we appreciate it, but please
stay relevant, and please don't be put off if we say "no" to
something. if we say "no" to some thing, try again with something
else.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[dennis.murata]

That is fine and your choice.  It doesn't seem like there is anything similar 
to an RFC process for systemd, so say that the "General Development and 
Discussion Mailing List" is changed to a new ML.  The name of this list is 
changed to "Developer and Technical question" but remains the same list, 
systemd-devel@lists.freedesktop.org, so that no one needs to re-subscribe.
There doesn't seem to be anything like an RFC process for systemd, so all the 
people who want to discuss changes in scope, changes in implementation strategy 
have a place to vent.  If you want to listen in you can, if you don't you don't 
have to see the emails in this list.

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Tomasz Torcz
Sent: Thursday, October 23, 2014 12:14 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of 
polarity and resistance

On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote:
> One thing I would like to point out, on the project website there is 
> NO mailing list for advocacy.  The comment "this is for technical email only 
> use a
> different ML" is for all purposes just a brush off.   If the project would
> create an advocacy mailing list it would go a long way toward 
> segregating the email.

  Who would participate in such list?  I wouldn't, personally.  I prefer 
technical discussions.
 
-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 21.10.14 11:25, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> > The "scopes" and "slices" concept does not exist elsewhere, and
> > there's nothing comparable around, so even if we wanted we couldn't
> > make logind work on anything else.
> 
> Then why in the first hand are the "scopes" and "slices" concepts within 
> systemd *tightly* coupled when it is functionality that makes sense to be 
> utilitizes in a component that provides a different functionality.

It's how people generally build systems: the lower layers provide basic
functionality, the upper layers then make use of.

To keep our code small and simple we do things that way. We don't
reimplement all functionality all the time on all levels, because we
don't want to make any assumptions about what the layers below us
provide us with.

> I wonder what functionality systemd provides right now in one more or less 
> tightly coupled package:
> 
> - early boot process
> - managing kernel drivers and device files (via coupled udev)
> - resource control for process groups
> - logging
> - core dumping
> - network while I think a distro-unified way to approaching network that 
> replaces the current distro specific ways like ifupdown and so on, why does 
> it 
> have to be coupled with systemd?

We maintain this stuff in one repository, and release it with
simultaneous release cycles. We can share tons of code that way, and
easily give it a uniform, integrated feel from the outside. 

Things like the core dumping or networkd are purely optional. If you
don't like them, don't use them.

> - cron, although that at least in Debian is separate as systemd-cron

Hmm? not sure what that is supposed to be. We have no "cron" in
systemd, only timer units.

> Way more than traditonal sysvinit covered.

yeah, systemd is a basic toolbox to build an OS from, sysvinit was
just a minimal init system, and nothing else.

> What of this actually *needs* to be coupled with systemd? What of this needs 
> to be coupled tightly to Linux kernel? 

No, nothing "needs" to be coupled. But it makes development for us
vastly simpler and the system altogether more uniform and smaller.

> systemd is driving a road where its all of this functionality by default is 
> only available for Linux and where upstream said they just won´t accept 
> patches – is that still true? – for portability. systemd provides more and 
> more functionality that desktops like to use, that other tools like
> to use.

We take portability patches for other archs, but not for other
kernels.

It's also really a pointless excercise, the BSDs or Solaris would
never adopt systemd anyway, I am not sure why you'd think
otherwise. They all have their own (unportable) service management
logic they don't make portable either. Most prominent is Solaris'
SMF which is tied closely do their "contract" ids, which is not
portable.

Moreover note that the BSDs at least actually are much stricter then
we are. We *just* put the moszt basic bits of the OS glue into one
repository and apply one common release cycle to it. On FreeBSD they
also maintain the libc and the kernel in the same framework and
schedule.

> When Microsoft back then did something like this it was called "Embrace, 
> Extend and Extinguish"¹…

Oh come on. You are just being a dick now. 

> a) Embrace: systemd provides functionality that is mostly compatible or 
> similar with what sysvinit and other components provided
> 
> b) Extend: systemd extends on that functionality and makes it more and more 
> difficult for desktops and apps to ignore that kind of functionality offers
> 
> c) Extinguish: The scope of systemd becomes so broad, the functionality it 
> offers in a – admittedly – convenient package to often needed and used, that 
> other ways of providing the functionality are extinguished.
> 
> Really… it matches quite closely.

No it doesn't. We provide you something for free. We don't care if you
use it or you don't. We don't take your freedom away by offering this
to you for free. Show some respect, man!

> I don´t think this was your plan. But… when looking at the currently visible 
> outcome this is quite exactly what is happening here.

Please, instead of making up your weird theories, actually do
something about things. I'd welcome any competition. It's really not
my fault if the people who actually like systemd appear to do almost
all work and thus adopt it. And the people who don't just sit around
and talk. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 23.10.2014 um 19:14 schrieb Tomasz Torcz:

On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote:

One thing I would like to point out, on the project website there is NO
mailing list for advocacy.  The comment "this is for technical email only use a
different ML" is for all purposes just a brush off.   If the project would
create an advocacy mailing list it would go a long way toward segregating the
email.


Who would participate in such list?  I wouldn't, personally.  I prefer
technical discussions.


that is fine, but than "use a different ML" means "use one which we 
don't read"




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tomasz Torcz]

On Thu, Oct 23, 2014 at 05:00:04PM +, dennis.mur...@wipro.com wrote:
> One thing I would like to point out, on the project website there is NO
> mailing list for advocacy.  The comment "this is for technical email only use 
> a
> different ML" is for all purposes just a brush off.   If the project would
> create an advocacy mailing list it would go a long way toward segregating the
> email. 

  Who would participate in such list?  I wouldn't, personally.  I prefer
technical discussions.
 
-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[dennis.murata]

One thing I would like to point out, on the project website there is NO mailing 
list for advocacy.  The comment "this is for technical email only use a 
different ML" is for all purposes just a brush off.   If the project would 
create an advocacy mailing list it would go a long way toward segregating the 
email.

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Cristian Rodríguez
Sent: Wednesday, October 22, 2014 7:27 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of 
polarity and resistance

El 22/10/14 a las #4, Rob Owens escribió:

> It is your ML, so I will oblige.  But I think it is a mistake to not consider 
> a broader view of your project than just the strictly technical aspects.

It is not *his* mailing list..but it is the place where *technical* discussions 
about the systemd project take place. I can only speak for myself but if you 
have been subscribed for a reasonable  amount of time,  you will see the 
concurrence is mostly if not completely only in the technical aspect and does 
not seem to have any interest on the topic of philosophical wanking.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Cristian Rodríguez]

El 22/10/14 a las #4, Rob Owens escribió:

> It is your ML, so I will oblige.  But I think it is a mistake to not consider 
> a broader view of your project than just the strictly technical aspects.

It is not *his* mailing list..but it is the place where *technical*
discussions about the systemd project take place. I can only speak for
myself but if you have been subscribed for a reasonable  amount of time,
 you will see the concurrence is mostly if not completely only in the
technical aspect and does not seem to have any interest on the topic of
philosophical wanking.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: Lennart Poettering 

> We are always interested in technical feedback. 
> 
> We are not very interested in FUD mails that tell us how we'd "force"
> people, how we'd behave like microsoft and so on. That's not useful,
> that's pretty much only hurtful. 

I haven't read this full thread, and it probably isn't useful for me
to do so.  But it seems that the first question to be answered by the
developers is:

Are they concerned that uptake is not as fast as they'd like?

and if the answer to that is Yes, then:

Would they like to hear feedback from users as to what they
might do about it?

There's no point in jabbering about it unless the answer to the second
question is Yes.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Lennart Poettering" 
> 
> On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote:
> 
> > > We are always interested in technical feedback.
> > 
> > I have seen this comment several times from the systemd devs, and I
> > don't doubt it.  But I think much of the criticism of systemd is not
> > technical. It has a more social/political nature, and I think you
> > should be interested in that feedback as well (even if it is
> > technically un-interesting).
> 
> Please, let's discuss this elsewhere. Let's keep a strict technical
> focus on this ML!
> 
> Thank you for your understanding!
> 
> Lennart

It is your ML, so I will oblige.  But I think it is a mistake to not consider a 
broader view of your project than just the strictly technical aspects.

-Rob
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Wed, 22.10.14 12:11, Rob Owens (row...@ptd.net) wrote:

> > We are always interested in technical feedback.
> 
> I have seen this comment several times from the systemd devs, and I
> don't doubt it.  But I think much of the criticism of systemd is not
> technical. It has a more social/political nature, and I think you
> should be interested in that feedback as well (even if it is
> technically un-interesting).

Please, let's discuss this elsewhere. Let's keep a strict technical
focus on this ML!

Thank you for your understanding!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Lennart Poettering" 

> We are always interested in technical feedback.

I have seen this comment several times from the systemd devs, and I don't doubt 
it.  But I think much of the criticism of systemd is not technical. It has a 
more social/political nature, and I think you should be interested in that 
feedback as well (even if it is technically un-interesting).

Here is an example of what I consider a social/political problem stemming from 
technical decisions:

Say you are a housing developer.  After many calculations, you have decided 
that the best design for housing is a cube.  It has a high 
volume-to-surface-area ratio, which allows it to house the most people with 
minimal heating/cooling loss to the outside environment.  It is easier to build 
than a sphere (which would have a higher volume-to-surface-area ratio).  To 
further maximize efficiency, each building will be a multi-unit dwelling.  
Interior units will have very little heat transfer to the outside, because the 
surrounding units help insulate them.

However, I don't want to share walls with another family, so I decide to buy a 
standalone house even though it is technically less efficient.  That's my 
choice, and choice is great, right.  But then I try to buy an air conditioner 
(cooling unit), and I find out that it is only compatible with your 
multi-dwelling cube house.  Why?  Because you have integrated some wonderful 
sensor technology into your buildings that the air conditioner manufacturer 
wants to take advantage of.  

So now I have a choice:  live in the house of my choice with no air 
conditioner, or live in your building with an air conditioner.

If you had designed your sensor system to be a separate piece, rather than 
integrating it directly into the building, I could buy any house I want and 
still have an air conditioner.  But because of your design choices (as well as 
the choices of the air conditioning manufacturer), my choice of housing is 
limited or even eliminated.  Tightly integrating the sensor system into the 
building may have been the technically best solution, but it has negative 
consequences in non-technical areas.

I hope you will give consideration to the non-technical as well as the 
technical when making your design decisions.

In case anybody's having trouble with the analogy:

The cube house is systemd.
The sensor technology is logind.
The air conditioner is pretty much any Gnome application.
The non-cube house is any other init system besides systemd.

-Rob
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Colin Guthrie]

Hello Martin,

Firstly, I apologise if you took what I said as a personal insult. It
was not my intention to do so (and I did try to make that explicitly
clear in a footnote).

I will certainly admit that some of my wording was more directed than I
had intended. This is something I would normally edit out and soften on
a read over, but time constraints didn't allow me that luxury.

That said, I do stand by my general comments. I will attempt a briefer
reply below [Spoiler: I failed!]

Martin Steigerwald wrote on 22/10/14 01:13:
> I received this twice on this mailing list. Once from Lennart ("being a dick 
> now") and now from you calling me a troll.

For the avoidance of doubt, I didn't directly call you a troll. I was
trying to point out that even well intentioned discussions, like yours,
cat at times become indistinguishable from a trolling discussion. Not
deliberate (which trolling is), but because no matter what reply is
sent, the participants will not be satisfied with the answers and will
continue the discussion. It would appear that this discussion has
reached that stage.

Over various points, there have been answers given and corrections made,
and yet still no acceptance is really given to those decisions - it's at
a time like this where further discussion is counter productive to your
goal and just serves to alienate people rather than get them any closer
to sharing your opinion.

> I will make an effort to reply to your mail and then most likely unsubscribe, 
> cause for me I feel like being in an hostile environment.

I disagree that this is a hostile environment. It's just that people
here will (by definition) generally just disagree with you. I apologise
if my reply was worded in an overly-hostile way (I'll try better in this
email), but ultimately you're going to get replies here that will
generally disagree with your stance.

>>> Thats rather much.
>>>
>>> Really rather much.
>>>
>>> Way more than traditonal sysvinit covered.
>>
>> This is because traditional sysvinit covered PID 1 and performing it's
>> job (if you consider e.g. killall5 and friends).
>>
>> You seem to be conflating systemd as PID 1 and systemd as a project.
>> These are two completely different things.
> 
> No. I am concerned about both. The functionality that is stuffed inside PID 1 
> which is more than 1,3 MiB and also sports user session functionality.

You use the term "stuffed" which is preloaded with negativity. Your
wording here would be better if you'd used the more neutral term
"included in" rather than "stuffed inside". By using this phrasing
you're already building up a barrier and will be polarising upstream
developers and will be reflected in their replies.

As another technical correction, PID 1 does NOT sport user session
functionality. It sports a general resource management concept (scopes
and slices) that is a userspace abstraction of the kernel cgroups
concept used for resource management. This is seen as core functionality
as it's PID1's job to fundamentally fork off other processes. I don't
think this is a point of contention.

Some people have argued that resource management should NOT be PID1's
job, and it should handled by a separate daemon. The argument thus far
from the systemd side is that doing this out of process would create a
chicken and egg problem. It's PID1's job to fork of processes and
configure their resources, but the "resource manager" processes' forking
would have to be special cased as there would be no "resource manager"
available when it was forked.  If this sub component fails, then PID1
fails too. It's so tightly coupled that the arguments for doing it out
of process are simply not sufficiently compelling, so this special
casing is not something systemd developers are comfortable with
technically due to both startup and runtime requirements.

The user session functionality you speak of is implemented outside of
PID1 in logind. Because it also needs to manager resources, it has to
work with the resource manager which, as described above, is PID1 in
systemd.

If other init systems want to do this differently they are welcome to do so.

>> An alternative would be to make the utility functions API stable and
>> export the shared library publicly and give API guarantees, but that
>> puts a lot of pressure and it's a difficult thing to provide and it has
>> long term maintenance overhead. This is something that *costs*. It costs
>> in time/man hours and therefore it carries real overheads. Doing this
>> for the convenience of splitting things out is simply not worth it -
>> especially so as the main people working on these things are the same
>> people.
> 
> I don´t think it would be just for the convenience of splitting things. It 
> would also be to address the concerns I summarized and that have been made 
> elsewhere. You may heard these concerns often, you may not agree to them. 
> Yet, 
> if you say later that some of these concerns were made 5 years ago already… 
> If 
> thos

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

Hi Martin,

If you were to phrase your complaints/questions in terms of technical
issues, we could probably have a much more useful debate. What is
clear is that the systemd project will not do or change anything
merely based on some bystanders gut feeling (which is basically what
you have argued from).

If you are concerned about portability, go ahead, follow the advice
given here, start the port and once you hit issues come back and ask
questions. Until someone does this, I think we should consider the
whole portability issue closed.

Same for modularity, make a fork (in the sense Colin used) of the
parts of systemd you want to use in isolation, and come back when you
run into problems (there surely will be some, but maybe you can still
do the things you want).

On Wed, Oct 22, 2014 at 2:13 AM, Martin Steigerwald  wrote:
> I will make an effort to reply to your mail and then most likely unsubscribe,
> cause for me I feel like being in an hostile environment.

When you ignore technical answers, and more than insinuate that we use
the same vile practices as Microsoft once did (despite you claiming
you don't mean to accuse anyone, the way it comes out is a quite
strong accusation), you should expect some less than friendly
responses. That said, I think Lennart and Colin both went after your
arguments not your person (if you bother reading carefully what they
wrote).

> No. I am concerned about both. The functionality that is stuffed inside PID 1
> which is more than 1,3 MiB and also sports user session functionality. And
> what is coupled inside on project, more or less tight.

I already answered the issue with user sessions (and so have others),
I'm disappointed that you would bring it up again without seeming to
have read our replies. As to the size of PID1, why don't you go and
study why this is so? The code is there, there are tools to study the
binary. Then hopefully you would either agree that the size is
unproblematic, or you would come up with some constructive
suggestions/patches to change things.

>> It also increases the test matrix. If logind v300 has to work with
>> libsystemd v300 and all future versions then the testing side of things
>> increases in complexity *massively*. Again this causes problems that
>> translate to time and effort of developers that could better be
>> allocated to building a better overall set of building blocks.
>
> I do think that the easiest way to do something is not necessarily the best.

If you think there is a better way to do things, go ahead, do it.
Vaguely complaining that we should have done this or that differently
is not going to change any minds. It is worth noting (again) that the
way we manage our repository does not mean that others could not make
replacements for parts of systemd, the stuff is very modular. But
don't take my word for it, start coding and when you run into problems
come back with questions.

You are probably not getting out of this discussion what you hoped for
(I assume). Sorry about that. If you come back with bug reports,
feature requests or patches, you will have a much easier time
influencing things.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[dennis.murata]

The system project seems to have made great strides to the point that now there 
are definite philosophical differences.  The people on both sides have their 
own opinions of what the direction should be given how much progress has 
occurred. 
I think this would a very good time for a fork of the project.  The systemd 
developers have rightly pointed out that this is free ware and if there is 
disagreement as has happened in the past, fork the project.
The people who disagree with the current direction have a solid base to build 
on, fork the project take it in the direction you feel it should go.
It will be interesting to see how the two sides progress.

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Martin Steigerwald
Sent: Tuesday, October 21, 2014 7:13 PM
To: Colin Guthrie
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] I wonder… why systemd provokes this amount of 
polarity and resistance

Colin,

I had the feeling that is a bad idea to read your mail before I go to sleep. 
But I was interested in what you have to say since you made quite an effort in 
your reply to me. And now I can´t sleep since my head if full of thoughts and I 
am full of emotions as well.

With that I perceive starts an answer on a technical matter ends with what I 
received as a dire personal attack: I.e. calling me names.

I received this twice on this mailing list. Once from Lennart ("being a dick
now") and now from you calling me a troll.

I will make an effort to reply to your mail and then most likely unsubscribe, 
cause for me I feel like being in an hostile environment.

Am Dienstag, 21. Oktober 2014, 22:14:48 schrieb Colin Guthrie:
> Martin Steigerwald wrote on 21/10/14 10:25:
> > Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
> >> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> >>> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> >>>> My question really isn't "why are the Debian dependencies the way 
> >>>> they are".  I understand that.  I was trying to highlight the 
> >>>> strange situation of a desktop application requiring a particular init 
> >>>> system.
> >>>> I *think* this is a result of the init portion of systemd being 
> >>>> bundled together with the logind portion of systemd.  To me 
> >>>> (unfamiliar with the systemd code) those two functions seem 
> >>>> distinct enough to merit being separate.  Debian can't easily 
> >>>> separate what the systemd devs have developed as a single binary, 
> >>>> so we end up with these strange dependency chains.>
> >>> 
> >>> "Single binary" is false of course. Logind is developed as a 
> >>> separate program, which is why systemd-shim is possible at all.
> >>> 
> >>> AFAIK the actual relevant dependencies go as follows: First, 
> >>> there's a good reason why logind requires cgroup functionality. 
> >>> And there's a good reason why cgroup functionality is best 
> >>> implemented together with init (see 
> >>> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInter
> >>> face/ for more info). So it's not quite directly "logind has to 
> >>> depend on systemd as init", but "logind has to depend on the 
> >>> system having cgroup support, and there's no equally good cgroup 
> >>> support available for inits other than systemd". It is possible to 
> >>> provide the relevant cgroup interfaces in or on top of another 
> >>> init, as the systemd-sysv + cgmanager combination attempts to do. 
> >>> But it is not trivial to do, as bugs and implementation delays 
> >>> with that combo have shown, and it's quite likely that there will 
> >>> be more problems in the future. It's not a particularly good idea 
> >>> to use the less-tested and less-reliable systemd-shim instead of 
> >>> the more reliable systemd. Thus the overall result is that yes, it 
> >>> does make sense to switch machines to systemd when you add certain 
> >>> functionality, even if that functionality does not appear to be 
> >>> directly tied to the init system at first glance.
> >> 
> >> Also note that the systemd concepts logind makes use of are also 
> >> exported in its own API. The "scopes" and "slices" that logind uses 
> >> are exposed on its bus objects, and they are used by tools like 
> >> "loginctl" to do their work.
> >> 
> &

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Uoti Urpala]

On Wed, 2014-10-22 at 02:13 +0200, Martin Steigerwald wrote:
> With that I perceive starts an answer on a technical matter ends with what I 
> received as a dire personal attack: I.e. calling me names.

I think it was a mostly justified criticism of your posting style here.

> I will make an effort to reply to your mail and then most likely unsubscribe, 
> cause for me I feel like being in an hostile environment.

If you post such strongly worded criticism of people's work (which I
don't consider really justified criticism either) then IMO you should
tolerate that level negative response without starting to complain about
"hostile environment".


> Upstream systemd has a very high development speed. Which you may view as 
> good. And heck, yes, it has its advantages I agree. But to me it also seems 
> that this speed partly come due to what you wrote above as the easy way of 
> developing things. And that easy way to develop things, I argue now, makes it 
> more difficult for people wanting to port to different platforms, people only 
> wanting a subset of systemd and people who want to adapt systemd.

Those latter are much smaller groups than the number of people who just
need a well-working init system for their Linux machine. It wouldn't
make sense to sacrifice the functionality of init just to make porting
easier.


> > > systemd provides more and
> > > more functionality that desktops like to use, that other tools like to
> > > use.
> > > 
> > > When Microsoft back then did something like this it was called "Embrace,
> > > Extend and Extinguish"¹…

> > > Really… it matches quite closely.
> > 
> > Oh come on! This is just an attack and FUD. You make repeated claims of
> > coming in good faith etc. and seem to dismiss any technical defence
> > being made with vague references and then you bring out a aggressive and
> > argumentative statement like the above.
> 
> That is the impression you get.
> 
> I think I replied to technical arguments as well.

The above does not match the definition of "Embrace, extend and
extinguish" (see for example the Wikipedia definition at
http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
). It's a lot more specific than just "a product manager to push
competing ones out of the market", and pretty much requires intentional
malice to apply. IMO it was quite accurate to call your claim
attack/FUD.


> What I tried to achieve is to describe and interpret what I see regarding the 
> state of systemd as I understand it now, and granted my understanding may not 
> be complete, sure, and also describe and interpret behavior I have seen. And 
> also summarize some of this from the feedback I read elsewhere.
> 
> What I didn´t try to achieve was attacking persons.
> 
> Yet, I interpret your reaction to me as if I attacked you.
> 
> So I am obviously not producing the outcome I wanted to produce. And thats 
> one 
> reason why I think I will stop doing what I am doing after this mail and 
> unsubscribe from this list for a while.
> 
> Actually I think I made my point. I tried to channel some of the dire 
> concerns 
> and uproar and polarity and split tendencies upstream.
> 
> I see this happening to my beloved distribution Debian and I am not happy 
> about it. The systemd debates and polarity within Debian I consider as being 
> harmful.
> 
> And it was my intention to address some of this upstream in order to discuss 
> what can be done to first *understand* why it triggers this polarity and what 
> can be done to address this.

Maybe your *intention* was to address reasons for controversy in a
constructive manner, but I do not think you succeeded very well. Several
of your points had already been made by others before - many, many
times. You bring up little that systemd authors would not have already
addressed before. Things like your "Embrace, extend and extinguish"
comparison above are attacks with little constructive content. And when
presented with technical justification to develop certain things in the
same project, or keep certain functionality in PID 1, you seem to
largely ignore it. Yes, it is a tradeoff, and you can always find some
negative side. But you won't achieve anything by ignoring the answers
and talking about the negative sides, if you can't make a better
argument why the tradeoff would be wrong overall.


> > Of course this criticism is listened to and often actions are taken
> > because of it, but what do you expect the outcome to be? Do you expect
> > all the repos to be split up? Stable APIs exported and supported? What
> > outcome do you actually *want* here? You seem to be doing lots of
> > complaining, but very little in the actual suggesting what could be done
> > different that has not already been addressed technically. You may
> > disagree about that end decision but that's just the way it is
> > sometimes? The people doing the work ultimately get to make the decisions.
> 
> Yeah, thats the do-ocracy aspect of things. Still if what I do aga

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Colin,

I had the feeling that is a bad idea to read your mail before I go to sleep. 
But I was interested in what you have to say since you made quite an effort in 
your reply to me. And now I can´t sleep since my head if full of thoughts and 
I am full of emotions as well.

With that I perceive starts an answer on a technical matter ends with what I 
received as a dire personal attack: I.e. calling me names.

I received this twice on this mailing list. Once from Lennart ("being a dick 
now") and now from you calling me a troll.

I will make an effort to reply to your mail and then most likely unsubscribe, 
cause for me I feel like being in an hostile environment.

Am Dienstag, 21. Oktober 2014, 22:14:48 schrieb Colin Guthrie:
> Martin Steigerwald wrote on 21/10/14 10:25:
> > Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
> >> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> >>> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
>  My question really isn't "why are the Debian dependencies the way they
>  are".  I understand that.  I was trying to highlight the strange
>  situation of a desktop application requiring a particular init system.
>  I *think* this is a result of the init portion of systemd being bundled
>  together with the logind portion of systemd.  To me (unfamiliar with
>  the systemd code) those two functions seem distinct enough to merit
>  being separate.  Debian can't easily separate what the systemd devs
>  have developed as a single binary, so we end up with these strange
>  dependency chains.>
> >>> 
> >>> "Single binary" is false of course. Logind is developed as a separate
> >>> program, which is why systemd-shim is possible at all.
> >>> 
> >>> AFAIK the actual relevant dependencies go as follows: First, there's a
> >>> good reason why logind requires cgroup functionality. And there's a good
> >>> reason why cgroup functionality is best implemented together with init
> >>> (see
> >>> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> >>> for more info). So it's not quite directly "logind has to depend on
> >>> systemd as init", but "logind has to depend on the system having cgroup
> >>> support, and there's no equally good cgroup support available for inits
> >>> other than systemd". It is possible to provide the relevant cgroup
> >>> interfaces in or on top of another init, as the systemd-sysv + cgmanager
> >>> combination attempts to do. But it is not trivial to do, as bugs and
> >>> implementation delays with that combo have shown, and it's quite likely
> >>> that there will be more problems in the future. It's not a particularly
> >>> good idea to use the less-tested and less-reliable systemd-shim instead
> >>> of the more reliable systemd. Thus the overall result is that yes, it
> >>> does make sense to switch machines to systemd when you add certain
> >>> functionality, even if that functionality does not appear to be directly
> >>> tied to the init system at first glance.
> >> 
> >> Also note that the systemd concepts logind makes use of are also
> >> exported in its own API. The "scopes" and "slices" that logind uses
> >> are exposed on its bus objects, and they are used by tools like
> >> "loginctl" to do their work.
> >> 
> >> The "scopes" and "slices" concept does not exist elsewhere, and
> >> there's nothing comparable around, so even if we wanted we couldn't
> >> make logind work on anything else.
> > 
> > Then why in the first hand are the "scopes" and "slices" concepts within
> > systemd *tightly* coupled when it is functionality that makes sense to be
> > utilitizes in a component that provides a different functionality.
> > 
> > I wonder what functionality systemd provides right now in one more or less
> > tightly coupled package:
> > 
> > - early boot process
> 
> PID 1
> 
> > - managing kernel drivers and device files (via coupled udev)
> 
> Not PID 1
> 
> > - resource control for process groups
> 
> PID 1.
> 
> > - logging
> 
> Not PID 1
> 
> > - core dumping
> 
> Not PID 1
> 
> > - network while I think a distro-unified way to approaching network that
> > replaces the current distro specific ways like ifupdown and so on, why
> > does it have to be coupled with systemd?
> 
> Not PID 1
> 
> > - cron, although that at least in Debian is separate as systemd-cron
> 
> Partly PID 1
> 
> > Thats rather much.
> > 
> > Really rather much.
> > 
> > Way more than traditonal sysvinit covered.
> 
> This is because traditional sysvinit covered PID 1 and performing it's
> job (if you consider e.g. killall5 and friends).
> 
> You seem to be conflating systemd as PID 1 and systemd as a project.
> These are two completely different things.

No. I am concerned about both. The functionality that is stuffed inside PID 1 
which is more than 1,3 MiB and also sports user session functionality. And 
what is coupled inside on project, more or less tight.

> There are many related thing

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Colin Guthrie]

Martin Steigerwald wrote on 21/10/14 10:25:
> Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
>> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
>>> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
 My question really isn't "why are the Debian dependencies the way they
 are".  I understand that.  I was trying to highlight the strange
 situation of a desktop application requiring a particular init system. 
 I *think* this is a result of the init portion of systemd being bundled
 together with the logind portion of systemd.  To me (unfamiliar with
 the systemd code) those two functions seem distinct enough to merit
 being separate.  Debian can't easily separate what the systemd devs
 have developed as a single binary, so we end up with these strange
 dependency chains.> 
>>> "Single binary" is false of course. Logind is developed as a separate
>>> program, which is why systemd-shim is possible at all.
>>>
>>> AFAIK the actual relevant dependencies go as follows: First, there's a
>>> good reason why logind requires cgroup functionality. And there's a good
>>> reason why cgroup functionality is best implemented together with init
>>> (see
>>> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
>>> for more info). So it's not quite directly "logind has to depend on
>>> systemd as init", but "logind has to depend on the system having cgroup
>>> support, and there's no equally good cgroup support available for inits
>>> other than systemd". It is possible to provide the relevant cgroup
>>> interfaces in or on top of another init, as the systemd-sysv + cgmanager
>>> combination attempts to do. But it is not trivial to do, as bugs and
>>> implementation delays with that combo have shown, and it's quite likely
>>> that there will be more problems in the future. It's not a particularly
>>> good idea to use the less-tested and less-reliable systemd-shim instead
>>> of the more reliable systemd. Thus the overall result is that yes, it
>>> does make sense to switch machines to systemd when you add certain
>>> functionality, even if that functionality does not appear to be directly
>>> tied to the init system at first glance.
>>
>> Also note that the systemd concepts logind makes use of are also
>> exported in its own API. The "scopes" and "slices" that logind uses
>> are exposed on its bus objects, and they are used by tools like
>> "loginctl" to do their work.
>>
>> The "scopes" and "slices" concept does not exist elsewhere, and
>> there's nothing comparable around, so even if we wanted we couldn't
>> make logind work on anything else.
> 
> Then why in the first hand are the "scopes" and "slices" concepts within 
> systemd *tightly* coupled when it is functionality that makes sense to be 
> utilitizes in a component that provides a different functionality.
> 
> I wonder what functionality systemd provides right now in one more or less 
> tightly coupled package:
> 
> - early boot process

PID 1

> - managing kernel drivers and device files (via coupled udev)

Not PID 1

> - resource control for process groups

PID 1.

> - logging

Not PID 1

> - core dumping

Not PID 1

> - network while I think a distro-unified way to approaching network that 
> replaces the current distro specific ways like ifupdown and so on, why does 
> it 
> have to be coupled with systemd?

Not PID 1

> - cron, although that at least in Debian is separate as systemd-cron

Partly PID 1

> Thats rather much.
> 
> Really rather much.
> 
> Way more than traditonal sysvinit covered.

This is because traditional sysvinit covered PID 1 and performing it's
job (if you consider e.g. killall5 and friends).

You seem to be conflating systemd as PID 1 and systemd as a project.
These are two completely different things.

There are many related things here and a lot of the sub components
obviously use a lot of the same functionality and utility functions.
This is achieved via a shared library with a private API.

The only reason that all these separate parts are developed as part of
the systemd project is that it's *easier*. It's just the easiest way to
develop.

An alternative would be to make the utility functions API stable and
export the shared library publicly and give API guarantees, but that
puts a lot of pressure and it's a difficult thing to provide and it has
long term maintenance overhead. This is something that *costs*. It costs
in time/man hours and therefore it carries real overheads. Doing this
for the convenience of splitting things out is simply not worth it -
especially so as the main people working on these things are the same
people.

It also increases the test matrix. If logind v300 has to work with
libsystemd v300 and all future versions then the testing side of things
increases in complexity *massively*. Again this causes problems that
translate to time and effort of developers that could better be
allocated to building a better overall set

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Simon McVittie]

On 21/10/14 09:37, Martin Steigerwald wrote:
> In my long years of using Debian and also doing some packages for it in the 
> last years I never saw that any introduced changed caused a serious "we may 
> need to fork" like announcement

I've seen several instances of Debian people *actually* forking it, and
that isn't one of them (at least, not yet). There are currently 63
derivatives listed on ,
variously booted via all the major init systems, and there are more that
are not listed on that page.

Perhaps the most prominent example is Ubuntu, which basically started as
a fork that would iterate faster and focus on ease-of-use, wandered off
into various subsequent goals from there, and incidentally funded
development of a new init system along the way. Another interesting
derivative is Tanglu, which is desktop-focused and has adopted systemd
much more aggressively than Debian.

Fundamentally, what needs to happen, if people want a version of Debian
that boots with LSB/sysvinit scripts to remain available indefinitely,
is for someone to do the work. That is all. They can do the work in
Debian or in a fork, whichever, but if the work is not done, the goal
will not be achieved. At the moment, I'm seeing a lot of noise, and a
lot of suggestions that the people who do the work should be coerced
into doing different work (which is unlikely to succeed in a volunteer
project), but a relatively small amount of actual software development
or maintenance.

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:59:09 schrieb Lennart Poettering:
> On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > > > So or so… I think its this kind of attitude that triggers most of the
> > > > polarity and split.
> > > 
> > > Well, our priority is to solve technical problems in a way we perceive
> > > elegant and minimal. Your priority appears to be appeasing people who
> > > prefer religious reasoning over technical reasoning. I am pretty sure
> > > you cannot appease those, and we will not compromise our technical
> > > necessesities for that.
> > > 
> > > Anyway, can we please end this discussion on this ML please? Please
> > > continue this somewhere else, this ML is really for technical
> > > discussions.
> > > 
> > > Sorry,
> > 
> > Well… actually I tried to discuss the concerns I and others have openly.
> > 
> > I went through the hassle to provide the feedback where it matters…
> > upstream… instead of joining the flamefests elsewhere or calling you
> > names…
> > 
> > … but it seems to me you are so sensitive to feedback that I don´t have
> > the
> > impression you even relate to the concerns I voiced here, which in part is
> > a summary of the part of concerns I read elsewhere I see as being
> > founded.
> We are always interested in technical feedback.
> 
> We are not very interested in FUD mails that tell us how we'd "force"
> people, how we'd behave like microsoft and so on. That's not useful,
> that's pretty much only hurtful.
> 
> Sorry,

I didn´t intend to hurt you. I am sorry if you used what I wrote to hurt 
yourself.

I just compared regarding the outcome. And to me there are similarities 
regarding the outcome.

I never said you intended this. I never said you behaved intently in this way.

That is *where* I differ from any of the personal accusation stuff.

I am not assuming bad intent.

Not at all.

But I see similarities in the outcome.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:52:50 schrieb Lennart Poettering:
> > When Microsoft back then did something like this it was called "Embrace, 
> > Extend and Extinguish"¹…
> 
> Oh come on. You are just being a dick now. 

For now just this:

Thats a personal accusation.

I didn´t attack you personally.

Please refrain from attacking me personally. Thats not the way of discussing I 
am willing to lower my communication into.

I shared my thoughts and observations… thats all.

To me what I perceive has similarities regarding the outcome. I didn´t say 
that it was your intention to create this. 

I specifically wrote:

> I don´t think this was your plan. But… when looking at the currently visible 
> outcome this is quite exactly what is happening here.

So I didn´t say anything about your intention. And how could I? I don´t know 
them.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 21.10.14 11:47, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> > > So or so… I think its this kind of attitude that triggers most of the
> > > polarity and split.
> > 
> > Well, our priority is to solve technical problems in a way we perceive
> > elegant and minimal. Your priority appears to be appeasing people who
> > prefer religious reasoning over technical reasoning. I am pretty sure
> > you cannot appease those, and we will not compromise our technical
> > necessesities for that.
> > 
> > Anyway, can we please end this discussion on this ML please? Please
> > continue this somewhere else, this ML is really for technical
> > discussions.
> > 
> > Sorry,
> 
> Well… actually I tried to discuss the concerns I and others have openly.
> 
> I went through the hassle to provide the feedback where it matters… upstream… 
> instead of joining the flamefests elsewhere or calling you names…
> 
> … but it seems to me you are so sensitive to feedback that I don´t have the 
> impression you even relate to the concerns I voiced here, which in part is a 
> summary of the part of concerns I read elsewhere I see as being founded.

We are always interested in technical feedback. 

We are not very interested in FUD mails that tell us how we'd "force"
people, how we'd behave like microsoft and so on. That's not useful,
that's pretty much only hurtful. 

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:21:36 schrieb Lennart Poettering:
> On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > So, aside from it being additional work, is there any *solid* or even
> > *unavoidable* technical reason to couple functionality that tightly?
> 
> Yes, there always is. For logind for example we need to be able to
> group the processes of a session, so that we can keep track of them,
> list them, kill them, get notifications about them, and so on. For
> that we need the "scope" concept of PID1. That's why logind talks to
> PID 1.
> 
> You know, it really annoys me if you imply that we just made these
> choices because we are assholes. We use the APIs we use because we
> need their technical functionality. It's that simple. It would be
> great if you'd grant us the benefit of the doubt at least, instead of
> implying anything else.

Lennart, I didn´t imply that, and I didn´t say that.

> > Wherever I look free software projects do great extra work to modularize
> > and separate out functionality that can be separate. For a reason. See
> > KDE community for example. They spend years of development work into
> > separating things out into separate packages and have a clear ruling on
> > what may depend on what. There are other examples for sure, OpenStack for
> > example, while I do not yet know it in detail consists of a ton of
> > separate packages in Debian.
> 
> Well, we are not KDE, and not OpenStack. We provide a basic toolbox to
> build an OS from. Compare us with Busybox if you must. I don't hear
> you complaining about busybox all the time!

Lennart, I get the impression you feel being accused. Yet I tried honestly to 
keep my mails to be polite and respectful. I tried to discuss about systemd 
and attitudes, not about persons.

Busybox is highly more optional than systemd. I can use bash and coreutils, or 
mksh and BSD commands or whatnot.

> > So or so… I think its this kind of attitude that triggers most of the
> > polarity and split.
> 
> Well, our priority is to solve technical problems in a way we perceive
> elegant and minimal. Your priority appears to be appeasing people who
> prefer religious reasoning over technical reasoning. I am pretty sure
> you cannot appease those, and we will not compromise our technical
> necessesities for that.
> 
> Anyway, can we please end this discussion on this ML please? Please
> continue this somewhere else, this ML is really for technical
> discussions.
> 
> Sorry,

Well… actually I tried to discuss the concerns I and others have openly.

I went through the hassle to provide the feedback where it matters… upstream… 
instead of joining the flamefests elsewhere or calling you names…

… but it seems to me you are so sensitive to feedback that I don´t have the 
impression you even relate to the concerns I voiced here, which in part is a 
summary of the part of concerns I read elsewhere I see as being founded.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

On Tue, Oct 21, 2014 at 11:35 AM, Martin Steigerwald
 wrote:
> Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie:
>> On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
>>
>>  wrote:
>> > Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
>> >> > Systemd-shim provides some functionality that systemd-sysv provides,
>> >> >
>> >> >  and allows admins to use init systems other than systemd while still
>> >> >  installing things like brasero.  I think this is a great thing,
>> >> >  except I wonder why the systemd project didn't separate this
>> >> >  functionality from the init system in the first place.  Systemd-shim
>> >> >  is a duplication of effort.  Not only that, but it must time its
>> >> >  releases with the releases of systemd-sysv.  That's no big deal for
>> >> >  Debian's stable release, but it can be problematic in Debian's
>> >> >  unstable and testing branches.
>> >>
>> >> Because it's additional work and complications. Apparently providing
>> >> systemd functionality without systemd running is not a trivial
>> >> undertaking, as the lag between systemd and systemd-shim releases
>> >> shows. I could spend my time for open source development on a
>> >> (technically) pointless (from my vantage point) split, but I
>> >> prefer to improve systemd instead.
>> >>
>> >> Debian as a project already paid significant to support systemd as an
>> >> alternative, when systemd version was held back for a year waiting
>> >> for systemd-shim to catch up. This is certainly not the last time.
>> >>
>> >> [snip]
>> >
>> > I think exactly this kind of attitude is what triggers most of the
>> > polarity
>> > around systemd.
>> >
>> > Its like "We don´t force systemd on anyone, but we provide as lots of
>> > functionality tightly coupled with it and if you do not implement it
>> > elsewhere, i.e. catch up, you need systemd anyway".
>> >
>> > While I believe it is *extra* work to separate functionality, I think it
>> > is
>> > *important* work. It would raise the acceptance of systemd, it would
>> > reduce
>> > the polarity it triggers. And it would make it more interoperable.
>> >
>> > Right now people are duplicating systemd stuff in several other areas. The
>> > reluctance to adopt systemd with certain distributions creates friction.
>> > Other implementations need to catch up and at any point in time may not
>> > be compatible.
>> >
>> > So, aside from it being additional work, is there any *solid* or even
>> > *unavoidable* technical reason to couple functionality that tightly?
>> >
>> > Wherever I look free software projects do great extra work to modularize
>> > and separate out functionality that can be separate. For a reason. See
>> > KDE community for example. They spend years of development work into
>> > separating things out into separate packages and have a clear ruling on
>> > what may depend on what. There are other examples for sure, OpenStack for
>> > example, while I do not yet know it in detail consists of a ton of
>> > separate packages in Debian.
>> >
>> > So or so… I think its this kind of attitude that triggers most of the
>> > polarity and split.
>>
>> Most of the modules in systemd do not depend on eachother. However,
>> logind does depend on the cgroups dbus API of systemd (PID1). In the
>> past logind interacted with the cgroups fs directly, but this had to
>> be changed as the kernel is moving to a model where only one process
>> may be in charge of cgroups. On systemd systems that one process is
>> PID1 (why that is so has been discussed elsewhere so won't repeat
>> that), so anything needing to deal with cgroups needs to go through
>> the systemd API.
>>
>> I hope that explains why logind has to depend on systemd (or at least
>> something implementing the systemd API).
>
> Thanks, Tom.
>
> As explained in another post – I didn´t read all the new answers… but it makes
> sense to do so – actually I feel uncomfortable about the new cgroup API. Its a
> kernel API. The Linux Kernel is a kernel supporting preemptive multitasking.
> Yet the new cgroup API requires or at least strongly recommends that only one
> process uses it. And… additionally to that that is a change that has been
> proposed by developers that to me oppinion are quite near or even working for
> systemd upstream.
>
> To me a single-process-usable API in the kernel seems broke. It may be hard to
> get the locking right… but still… I think the current cgroup API is still as
> broke as it can get. The unified hierarchy approach makes some sense to me, 
> but
> requiring that only one process modifies it, instead of providing an API
> mutiple processes can use just seems plain broke to me.
>
> And I know, thats probably something to raise on LKML. And I may be inclined
> to do so.

The systemd project does not have much (any?) influence over what
interfaces the kernel provides, so I suggest you take your concerns up
with them. That said, you will likely get further with technical
arguments, and prefer

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:26:16 schrieben Sie:
> On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
> 
>  wrote:
> > Then systemd may use it as PID 1, but if someother wants to use it in own
> > project, can use it as well. I consider cgroups as part of the kernel API
> > and I highly dislike the battle on which of the available solutions will
> > get control over it. Actually I still think the API is broke if it cannot
> > allow for mutiple processes accessing it. I don´t know an easy way to fix
> > it, but I think such a kind of API as kernel interface… anyone can read a
> > file, mount a filesystem, open a network socket, set a nice value
> > depending on permissions but when it comes to control groups it is down
> > to "one to rule them all". I can´t help it, but this just seems utterly
> > broke to me.
> > 
> > I can´t help it but I don´t consider this to be a sane operating system
> > API.
> Note that the maintainers of the kernel-side cgroup API (primarily
> Tejun Heo, AFAIK) consider the current interface insane. In the
> future, the kernel will expect a single userspace process to control a
> single hierarchy. Systemd has already been adapted to provide this
> schema using the current API. See
> http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html

Well I concur with that.

I think the mutiple hierarchy API is inconsistent and insane. I see the point 
of having a unified hierarchy. But I never understand the requirement of one 
process controlling it and then having a battle over which process it will be.

Whereever else we had something like this, it was tightly reduced to one 
functionality and available separate. Like udev, but still tightly coupled 
with the kernel and free to anyone to use – *just* this part of the 
functionality. Just like the Performance Events with the perf tools. Or 
iproute. Or you name it: Everyone providing one functionality. And… in its 
part being replacable.

But with systemd it appears to be an all or nothing approach. I don´t only get 
control groups, but everything else… or else I need to duplicate the 
functionality myself.

That just doesn´t make any sense to me. For udev I had the impression it was 
some quite approved part of the Linux kernel userspace utility.

So while I think the old mutiple hierarchy API is broke, and heck I teached it 
in my Linux Performance analysis and tuning courses… I do think the new API is 
broke as well.

Sometimes I think better ditch it all and redo it from scratch.

Anyone can open a file, mount a fs, set a nice value, but only one process can 
do resource control of process groups via cgroups. This doesn´t make any sense 
to me.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 21.10.14 11:08, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> > systemd as init", but "logind has to depend on the system having cgroup
> > support, and there's no equally good cgroup support available for inits
> > other than systemd". It is possible to provide the relevant cgroup
> > interfaces in or on top of another init, as the systemd-sysv + cgmanager
> > combination attempts to do. But it is not trivial to do, as bugs and
> > implementation delays with that combo have shown, and it's quite likely
> > that there will be more problems in the future. It's not a particularly
> > good idea to use the less-tested and less-reliable systemd-shim instead
> > of the more reliable systemd. Thus the overall result is that yes, it
> > does make sense to switch machines to systemd when you add certain
> > functionality, even if that functionality does not appear to be directly
> > tied to the init system at first glance.
> 
> I can´t point my finger at it why… but I really feel uncomfortable with this 
> tight coupling. I think that the systemd-shim + cgmanager combination may 
> have 
> bugs does not *prove* that such a think isn´t workable.

Well, you can do tons of things, that simple fact doesn't really make
all of them a good idea.

PID1 is supposed to start and maintain services. In our eyes this is
best done with cgroups, because that allows us to keep track of the
service processes, label them, list them, kill them, get notifications
about them. All this functionality is implicitly done by the kernel
for us, we just need to make use of it, with a few mkdir()s and
open()+write()s, awesome! That's why we use it.

Now, of course you can split that out in multiple daemons, but then
you have to do IPC between these daemons. That's already bad enough,
for complexity and stability reasons. However, what's worse is that it
creates a chicken and egg problem: if PID forks of a service like
cgmanager in order to *manage* a service like cgmanager, then you have
a cyclic dependency. You can of course hackishly work around this, but
this would mean to exclude cgmanager from service supervision. And
moreover: for what even? For executing a few mkdir()s and write()s
out-of-process? Really?

Hence: while these things are certainly possible I am strongly of the
opinion that they would be a systematically bad design, and we will
hence not do such a fuckup in systemd. Sorry.

> But due to the design choice of you systemd developers to have it all in one 
> people who do believe that separating different functionality is for the long 
> term benefit of interoperability and avoiding what I´d call vendor lock in, 
> although I clearly see that systemd upstream community isn´t a single vendor 
> as in one company who produces a comercial product.

We are open source. There is no such thing as vendor lockin. You are
just fudding around now. I really don't appreciate what you are
writing here.

This has been discussed a million times before. If you want to discuss
this again then find another forum.

> In other areas where the Linux kernel requires user space helpers things 
> initially have been separated. The whole do it all in once hald daemon was 
> split into udev, libudev, udisks and upower… yet now, systemd and udev is in 
> one upstream again.

I think you misunderstand the history of hal really.

> What speaks against putting the cgroup functionality and other stuff from 
> systemd into shared libraries with clearly defined APIs – which are 
> documented 
> and where the documentation is the reference, not the source code – and 
> allowing it to be used elsewhere?

See above.

Our APIs are actually pretty well documented, in documentation, not
source code. You seem to imply otherwise. What do you want more
documentation for? Can you be more explicit please?

> Then systemd may use it as PID 1, but if someother wants to use it in own 
> project, can use it as well. I consider cgroups as part of the kernel API and 
> I highly dislike the battle on which of the available solutions will get 
> control over it. Actually I still think the API is broke if it cannot allow 
> for mutiple processes accessing it. I don´t know an easy way to fix it, but I 
> think such a kind of API as kernel interface… anyone can read a file, mount a 
> filesystem, open a network socket, set a nice value depending on permissions 
> but when it comes to control groups it is down to "one to rule them all". I 
> can´t help it, but this just seems utterly broke to me.

Well, if you think the cgroup interface is broken, please bring this
up with the kernel folks not us.

> I can´t help it but I don´t consider this to be a sane operating
> system API.

Maybe instead of criticising the kernel folks and us for technical
choices you should really get your hands dirty and try to make it
better?

> > The issue with "I should be able to stay with sysvinit because it worked
> > fine for me" is that keeping sysvinit working is COSTLY. The reason
> > 

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:07:01 schrieben Sie:
> On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
> 
>  wrote:
> > Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
> >> > Systemd-shim provides some functionality that systemd-sysv provides,
> >> > 
> >> >  and allows admins to use init systems other than systemd while still
> >> >  installing things like brasero.  I think this is a great thing,
> >> >  except I wonder why the systemd project didn't separate this
> >> >  functionality from the init system in the first place.  Systemd-shim
> >> >  is a duplication of effort.  Not only that, but it must time its
> >> >  releases with the releases of systemd-sysv.  That's no big deal for
> >> >  Debian's stable release, but it can be problematic in Debian's
> >> >  unstable and testing branches.
> >> 
> >> Because it's additional work and complications. Apparently providing
> >> systemd functionality without systemd running is not a trivial
> >> undertaking, as the lag between systemd and systemd-shim releases
> >> shows. I could spend my time for open source development on a
> >> (technically) pointless (from my vantage point) split, but I
> >> prefer to improve systemd instead.
> >> 
> >> Debian as a project already paid significant to support systemd as an
> >> alternative, when systemd version was held back for a year waiting
> >> for systemd-shim to catch up. This is certainly not the last time.
> >> 
> >> [snip]
> > 
> > I think exactly this kind of attitude is what triggers most of the
> > polarity
> > around systemd.
> > 
> > Its like "We don´t force systemd on anyone, but we provide as lots of
> > functionality tightly coupled with it and if you do not implement it
> > elsewhere, i.e. catch up, you need systemd anyway".
> > 
> > While I believe it is *extra* work to separate functionality, I think it
> > is
> > *important* work. It would raise the acceptance of systemd, it would
> > reduce
> > the polarity it triggers. And it would make it more interoperable.
> > 
> > Right now people are duplicating systemd stuff in several other areas. The
> > reluctance to adopt systemd with certain distributions creates friction.
> > Other implementations need to catch up and at any point in time may not
> > be compatible.
> > 
> > So, aside from it being additional work, is there any *solid* or even
> > *unavoidable* technical reason to couple functionality that tightly?
> > 
> > Wherever I look free software projects do great extra work to modularize
> > and separate out functionality that can be separate. For a reason. See
> > KDE community for example. They spend years of development work into
> > separating things out into separate packages and have a clear ruling on
> > what may depend on what. There are other examples for sure, OpenStack for
> > example, while I do not yet know it in detail consists of a ton of
> > separate packages in Debian.
> > 
> > So or so… I think its this kind of attitude that triggers most of the
> > polarity and split.
> 
> Most of the modules in systemd do not depend on eachother. However,
> logind does depend on the cgroups dbus API of systemd (PID1). In the
> past logind interacted with the cgroups fs directly, but this had to
> be changed as the kernel is moving to a model where only one process
> may be in charge of cgroups. On systemd systems that one process is
> PID1 (why that is so has been discussed elsewhere so won't repeat
> that), so anything needing to deal with cgroups needs to go through
> the systemd API.
> 
> I hope that explains why logind has to depend on systemd (or at least
> something implementing the systemd API).

Thanks, Tom.

As explained in another post – I didn´t read all the new answers… but it makes 
sense to do so – actually I feel uncomfortable about the new cgroup API. Its a 
kernel API. The Linux Kernel is a kernel supporting preemptive multitasking. 
Yet the new cgroup API requires or at least strongly recommends that only one 
process uses it. And… additionally to that that is a change that has been 
proposed by developers that to me oppinion are quite near or even working for 
systemd upstream.

To me a single-process-usable API in the kernel seems broke. It may be hard to 
get the locking right… but still… I think the current cgroup API is still as 
broke as it can get. The unified hierarchy approach makes some sense to me, but 
requiring that only one process modifies it, instead of providing an API 
mutiple processes can use just seems plain broke to me.

And I know, thats probably something to raise on LKML. And I may be inclined 
to do so.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jan Alexander Steffens]

On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
 wrote:
> Then systemd may use it as PID 1, but if someother wants to use it in own
> project, can use it as well. I consider cgroups as part of the kernel API and
> I highly dislike the battle on which of the available solutions will get
> control over it. Actually I still think the API is broke if it cannot allow
> for mutiple processes accessing it. I don´t know an easy way to fix it, but I
> think such a kind of API as kernel interface… anyone can read a file, mount a
> filesystem, open a network socket, set a nice value depending on permissions
> but when it comes to control groups it is down to "one to rule them all". I
> can´t help it, but this just seems utterly broke to me.
>
> I can´t help it but I don´t consider this to be a sane operating system API.

Note that the maintainers of the kernel-side cgroup API (primarily
Tejun Heo, AFAIK) consider the current interface insane. In the
future, the kernel will expect a single userspace process to control a
single hierarchy. Systemd has already been adapted to provide this
schema using the current API. See
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Mittwoch, 8. Oktober 2014, 10:54:00 schrieb Lennart Poettering:
> On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > > My question really isn't "why are the Debian dependencies the way they
> > > are".  I understand that.  I was trying to highlight the strange
> > > situation of a desktop application requiring a particular init system. 
> > > I *think* this is a result of the init portion of systemd being bundled
> > > together with the logind portion of systemd.  To me (unfamiliar with
> > > the systemd code) those two functions seem distinct enough to merit
> > > being separate.  Debian can't easily separate what the systemd devs
> > > have developed as a single binary, so we end up with these strange
> > > dependency chains.> 
> > "Single binary" is false of course. Logind is developed as a separate
> > program, which is why systemd-shim is possible at all.
> > 
> > AFAIK the actual relevant dependencies go as follows: First, there's a
> > good reason why logind requires cgroup functionality. And there's a good
> > reason why cgroup functionality is best implemented together with init
> > (see
> > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> > for more info). So it's not quite directly "logind has to depend on
> > systemd as init", but "logind has to depend on the system having cgroup
> > support, and there's no equally good cgroup support available for inits
> > other than systemd". It is possible to provide the relevant cgroup
> > interfaces in or on top of another init, as the systemd-sysv + cgmanager
> > combination attempts to do. But it is not trivial to do, as bugs and
> > implementation delays with that combo have shown, and it's quite likely
> > that there will be more problems in the future. It's not a particularly
> > good idea to use the less-tested and less-reliable systemd-shim instead
> > of the more reliable systemd. Thus the overall result is that yes, it
> > does make sense to switch machines to systemd when you add certain
> > functionality, even if that functionality does not appear to be directly
> > tied to the init system at first glance.
> 
> Also note that the systemd concepts logind makes use of are also
> exported in its own API. The "scopes" and "slices" that logind uses
> are exposed on its bus objects, and they are used by tools like
> "loginctl" to do their work.
> 
> The "scopes" and "slices" concept does not exist elsewhere, and
> there's nothing comparable around, so even if we wanted we couldn't
> make logind work on anything else.

Then why in the first hand are the "scopes" and "slices" concepts within 
systemd *tightly* coupled when it is functionality that makes sense to be 
utilitizes in a component that provides a different functionality.

I wonder what functionality systemd provides right now in one more or less 
tightly coupled package:

- early boot process
- managing kernel drivers and device files (via coupled udev)
- resource control for process groups
- logging
- core dumping
- network while I think a distro-unified way to approaching network that 
replaces the current distro specific ways like ifupdown and so on, why does it 
have to be coupled with systemd?
- cron, although that at least in Debian is separate as systemd-cron
 
Thats rather much.

Really rather much.

Way more than traditonal sysvinit covered.

What of this actually *needs* to be coupled with systemd? What of this needs 
to be coupled tightly to Linux kernel? 

systemd is driving a road where its all of this functionality by default is 
only available for Linux and where upstream said they just won´t accept 
patches – is that still true? – for portability. systemd provides more and 
more functionality that desktops like to use, that other tools like to use.

When Microsoft back then did something like this it was called "Embrace, 
Extend and Extinguish"¹…

a) Embrace: systemd provides functionality that is mostly compatible or 
similar with what sysvinit and other components provided

b) Extend: systemd extends on that functionality and makes it more and more 
difficult for desktops and apps to ignore that kind of functionality offers

c) Extinguish: The scope of systemd becomes so broad, the functionality it 
offers in a – admittedly – convenient package to often needed and used, that 
other ways of providing the functionality are extinguished.

Really… it matches quite closely.

I don´t think this was your plan. But… when looking at the currently visible 
outcome this is quite exactly what is happening here.

So if you can follow this just a tiny bit: Do you start to understand why 
systemd triggers the uproar, polarity and split so obvious that one needs to 
have hands before both eyes for not seeing it?

So as I see it: there are *real* concerns. And if systemd is meant to be a 
tool for users and admins, I *highly* and *strongly* recommend that you as 
systemd closely look at

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 21.10.14 10:53, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> So, aside from it being additional work, is there any *solid* or even 
> *unavoidable* technical reason to couple functionality that tightly?

Yes, there always is. For logind for example we need to be able to
group the processes of a session, so that we can keep track of them,
list them, kill them, get notifications about them, and so on. For
that we need the "scope" concept of PID1. That's why logind talks to
PID 1.

You know, it really annoys me if you imply that we just made these
choices because we are assholes. We use the APIs we use because we
need their technical functionality. It's that simple. It would be
great if you'd grant us the benefit of the doubt at least, instead of
implying anything else. 

> Wherever I look free software projects do great extra work to modularize and 
> separate out functionality that can be separate. For a reason. See KDE 
> community for example. They spend years of development work into separating 
> things out into separate packages and have a clear ruling on what may depend 
> on what. There are other examples for sure, OpenStack for example, while I do 
> not yet know it in detail consists of a ton of separate packages in
> Debian.

Well, we are not KDE, and not OpenStack. We provide a basic toolbox to
build an OS from. Compare us with Busybox if you must. I don't hear
you complaining about busybox all the time!

> So or so… I think its this kind of attitude that triggers most of the 
> polarity 
> and split.

Well, our priority is to solve technical problems in a way we perceive
elegant and minimal. Your priority appears to be appeasing people who
prefer religious reasoning over technical reasoning. I am pretty sure
you cannot appease those, and we will not compromise our technical
necessesities for that.

Anyway, can we please end this discussion on this ML please? Please
continue this somewhere else, this ML is really for technical
discussions.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 7. Oktober 2014, 23:40:45 schrieb Uoti Urpala:
> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > My question really isn't "why are the Debian dependencies the way they
> > are".  I understand that.  I was trying to highlight the strange
> > situation of a desktop application requiring a particular init system.  I
> > *think* this is a result of the init portion of systemd being bundled
> > together with the logind portion of systemd.  To me (unfamiliar with the
> > systemd code) those two functions seem distinct enough to merit being
> > separate.  Debian can't easily separate what the systemd devs have
> > developed as a single binary, so we end up with these strange dependency
> > chains.
> "Single binary" is false of course. Logind is developed as a separate
> program, which is why systemd-shim is possible at all.
> 
> AFAIK the actual relevant dependencies go as follows: First, there's a
> good reason why logind requires cgroup functionality. And there's a good
> reason why cgroup functionality is best implemented together with init
> (see
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> for more info). So it's not quite directly "logind has to depend on
> systemd as init", but "logind has to depend on the system having cgroup
> support, and there's no equally good cgroup support available for inits
> other than systemd". It is possible to provide the relevant cgroup
> interfaces in or on top of another init, as the systemd-sysv + cgmanager
> combination attempts to do. But it is not trivial to do, as bugs and
> implementation delays with that combo have shown, and it's quite likely
> that there will be more problems in the future. It's not a particularly
> good idea to use the less-tested and less-reliable systemd-shim instead
> of the more reliable systemd. Thus the overall result is that yes, it
> does make sense to switch machines to systemd when you add certain
> functionality, even if that functionality does not appear to be directly
> tied to the init system at first glance.

I can´t point my finger at it why… but I really feel uncomfortable with this 
tight coupling. I think that the systemd-shim + cgmanager combination may have 
bugs does not *prove* that such a think isn´t workable.

But due to the design choice of you systemd developers to have it all in one 
people who do believe that separating different functionality is for the long 
term benefit of interoperability and avoiding what I´d call vendor lock in, 
although I clearly see that systemd upstream community isn´t a single vendor 
as in one company who produces a comercial product.

In other areas where the Linux kernel requires user space helpers things 
initially have been separated. The whole do it all in once hald daemon was 
split into udev, libudev, udisks and upower… yet now, systemd and udev is in 
one upstream again.

What speaks against putting the cgroup functionality and other stuff from 
systemd into shared libraries with clearly defined APIs – which are documented 
and where the documentation is the reference, not the source code – and 
allowing it to be used elsewhere?

Then systemd may use it as PID 1, but if someother wants to use it in own 
project, can use it as well. I consider cgroups as part of the kernel API and 
I highly dislike the battle on which of the available solutions will get 
control over it. Actually I still think the API is broke if it cannot allow 
for mutiple processes accessing it. I don´t know an easy way to fix it, but I 
think such a kind of API as kernel interface… anyone can read a file, mount a 
filesystem, open a network socket, set a nice value depending on permissions 
but when it comes to control groups it is down to "one to rule them all". I 
can´t help it, but this just seems utterly broke to me.

I can´t help it but I don´t consider this to be a sane operating system API.

> > I never thought much about my init system until recently.  I never really
> > had any complaints with SysV init, although I do recognize that systemd
> > provides real improvements for some use cases.  So for me as a sysadmin
> > the wisest thing to do is stick with what I already know, as long as it's
> > working well enough (and for me, it is).
> The issue with "I should be able to stay with sysvinit because it worked
> fine for me" is that keeping sysvinit working is COSTLY. The reason
> sysvinit used to mostly work was not that it would have been a reliable
> system - it mostly worked because people kept using a lot of effort to
> work around and paper over various issues that kept popping up. And
> there's no justification to keep up that effort for the minority who
> wants to stay with sysvinit. So, you can keep running your old systems
> unchanged if you want, but you shouldn't expect to be able to upgrade
> them or install new software without switching to systemd.

What you write here basically comes down to a forced adoption. At least this 
is how I rece

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

On Tue, Oct 21, 2014 at 10:53 AM, Martin Steigerwald
 wrote:
> Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
>> > Systemd-shim provides some functionality that systemd-sysv provides,
>> >  and allows admins to use init systems other than systemd while still
>> >  installing things like brasero.  I think this is a great thing,
>> >  except I wonder why the systemd project didn't separate this
>> >  functionality from the init system in the first place.  Systemd-shim
>> >  is a duplication of effort.  Not only that, but it must time its
>> >  releases with the releases of systemd-sysv.  That's no big deal for
>> >  Debian's stable release, but it can be problematic in Debian's
>> >  unstable and testing branches.
>>
>> Because it's additional work and complications. Apparently providing
>> systemd functionality without systemd running is not a trivial
>> undertaking, as the lag between systemd and systemd-shim releases
>> shows. I could spend my time for open source development on a
>> (technically) pointless (from my vantage point) split, but I
>> prefer to improve systemd instead.
>>
>> Debian as a project already paid significant to support systemd as an
>> alternative, when systemd version was held back for a year waiting
>> for systemd-shim to catch up. This is certainly not the last time.
>>
>> [snip]
>
> I think exactly this kind of attitude is what triggers most of the polarity
> around systemd.
>
> Its like "We don´t force systemd on anyone, but we provide as lots of
> functionality tightly coupled with it and if you do not implement it
> elsewhere, i.e. catch up, you need systemd anyway".
>
> While I believe it is *extra* work to separate functionality, I think it is
> *important* work. It would raise the acceptance of systemd, it would reduce
> the polarity it triggers. And it would make it more interoperable.
>
> Right now people are duplicating systemd stuff in several other areas. The
> reluctance to adopt systemd with certain distributions creates friction. Other
> implementations need to catch up and at any point in time may not be
> compatible.
>
> So, aside from it being additional work, is there any *solid* or even
> *unavoidable* technical reason to couple functionality that tightly?
>
> Wherever I look free software projects do great extra work to modularize and
> separate out functionality that can be separate. For a reason. See KDE
> community for example. They spend years of development work into separating
> things out into separate packages and have a clear ruling on what may depend
> on what. There are other examples for sure, OpenStack for example, while I do
> not yet know it in detail consists of a ton of separate packages in Debian.
>
> So or so… I think its this kind of attitude that triggers most of the polarity
> and split.

Most of the modules in systemd do not depend on eachother. However,
logind does depend on the cgroups dbus API of systemd (PID1). In the
past logind interacted with the cgroups fs directly, but this had to
be changed as the kernel is moving to a model where only one process
may be in charge of cgroups. On systemd systems that one process is
PID1 (why that is so has been discussed elsewhere so won't repeat
that), so anything needing to deal with cgroups needs to go through
the systemd API.

I hope that explains why logind has to depend on systemd (or at least
something implementing the systemd API).

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Montag, 6. Oktober 2014, 21:53:04 schrieb Zbigniew Jędrzejewski-Szmek:
> > Systemd-shim provides some functionality that systemd-sysv provides,
> >  and allows admins to use init systems other than systemd while still
> >  installing things like brasero.  I think this is a great thing,
> >  except I wonder why the systemd project didn't separate this
> >  functionality from the init system in the first place.  Systemd-shim
> >  is a duplication of effort.  Not only that, but it must time its
> >  releases with the releases of systemd-sysv.  That's no big deal for
> >  Debian's stable release, but it can be problematic in Debian's
> >  unstable and testing branches.
> 
> Because it's additional work and complications. Apparently providing
> systemd functionality without systemd running is not a trivial
> undertaking, as the lag between systemd and systemd-shim releases
> shows. I could spend my time for open source development on a
> (technically) pointless (from my vantage point) split, but I
> prefer to improve systemd instead.
> 
> Debian as a project already paid significant to support systemd as an
> alternative, when systemd version was held back for a year waiting
> for systemd-shim to catch up. This is certainly not the last time.
> 
> [snip]

I think exactly this kind of attitude is what triggers most of the polarity 
around systemd.

Its like "We don´t force systemd on anyone, but we provide as lots of 
functionality tightly coupled with it and if you do not implement it 
elsewhere, i.e. catch up, you need systemd anyway".

While I believe it is *extra* work to separate functionality, I think it is 
*important* work. It would raise the acceptance of systemd, it would reduce 
the polarity it triggers. And it would make it more interoperable.

Right now people are duplicating systemd stuff in several other areas. The 
reluctance to adopt systemd with certain distributions creates friction. Other 
implementations need to catch up and at any point in time may not be 
compatible.

So, aside from it being additional work, is there any *solid* or even 
*unavoidable* technical reason to couple functionality that tightly?

Wherever I look free software projects do great extra work to modularize and 
separate out functionality that can be separate. For a reason. See KDE 
community for example. They spend years of development work into separating 
things out into separate packages and have a clear ruling on what may depend 
on what. There are other examples for sure, OpenStack for example, while I do 
not yet know it in detail consists of a ton of separate packages in Debian.

So or so… I think its this kind of attitude that triggers most of the polarity 
and split.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Hi Rob,

Am Montag, 6. Oktober 2014, 14:56:22 schrieb Rob Owens:
> - Original Message -
> 
> > From: "Martin Steigerwald" 
> > 
> > Heck, I started a thread here and then didn´t manage to take time to
> > carefully
> > read it and reply here and there as I see fit. But I challenged people on
> > debian-user mailing list to constructively voice their concerns upstream,
> > and even pointed them to this mailing list. As far as I saw *no one* of
> > the posters in debian-user took up on that challenge. Which I view as a
> > pity. Cause now actually you invited constructive feedback. I wonder
> > whether I may forward your answer to debian-user so they see your
> > statement of inviting constructive feedback.
> 
> I am here from debian-user, due to Martin's suggestion.  So now that he's
> calling me out, I guess I'll post my questions :)
> 
> For the record, I'm a sysadmin and not a developer.  I imagine my questions
> and opinions will reflect that.

Thank you for voicing your concerns as one of the many users who where not so 
hesitant to voice their concerns on the debian-user mailing list.

> > Here the feedback I read over and over again is that you and RedHat
> > basically forced the systemd decision onto other distributions. While I
> > do not see how you actually can be powerful enough to do that, as we live
> > in a free will zone. I do see tendencies that more and more stuff
> > *depends* on systemd cause it needs features only available there.
> > 
> > On of the most talked on things on debian-user is the logind thing. GNOME
> > actually depends on it, as far as I know. While KDE in Debian still uses
> 
> > ConsoleKit, as it seems to me when looking at the process list and finding:
> On Debian, I came across an unusual dependency.  Installing a cd burner
> (brasero) required me to change my init system to systemd.  Sounds kind of
> ridiculous, I think.  The dependency chain went like this:
> 
> brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv

I really find this kind of chain quite ridiculous.

But if its breakable at least as Martin told… still.

I think its important to make sure that installing brasero does not 
accidentally switch a sysvinit system to systemd. As it would be the least a 
user would expect here and from common sense it does not even make sense. It 
may make sense technically as explained, but from a user and sysadmin point of 
view it does not make any sense at all and is quite disruptive.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Sonntag, 21. September 2014, 15:31:15 schrieb Martin Steigerwald:
> Hello!
> 
> I know this is a daring post.
> 
> I just have one question. In the light of
> 
> http://boycottsystemd.org/
> 
> http://uselessd.darknedgy.net/
> 
> developing some systemd compatible services for BSD:
> http://undeadly.org/cgi?action=article&sid=20140915064856
> 
> 
> in the light of
> 
> Debian Bug report logs - #727708
> tech-ctte: Decide which init system to default to in Debian.
> https://bugs.debian.org/727708
> 
> 
> Debian Bug report logs - #746715
> the foreseeable outcome of the TC vote on init systems
> https://bugs.debian.org/bug=746715
> 
> 
> in the light of the ongoing discussions on linux-kernel, debian-devel,
> debian- user and other mailing lists more than some dozens threads
> meanwhile:

In my long years of using Debian and also doing some packages for it in the 
last years I never saw that any introduced changed caused a serious "we may 
need to fork" like announcement like this:

http://debianfork.org/

Also the upcoming GR decision about whether to require that packages may not 
depend on PID 1 it refers to.

I think I never saw that kind of uproar in Debian. In my view its worrying and 
damaging. And I think it points at a real problem.

There is a dire problem with the acceptance of systemd in Debian (and not only 
there). In Debian this is not only with users, but also with developers.

Wherever I look systemd triggers a split into "pro" and "contra". Even here at 
work. I still use it, I test it, it seems to work. But I am concerned. Some 
co-workers dislike it highly.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> > My question really isn't "why are the Debian dependencies the way they 
> > are".  I understand that.  I was trying to highlight the strange situation 
> > of a desktop application requiring a particular init system.  I *think* 
> > this is a result of the init portion of systemd being bundled together with 
> > the logind portion of systemd.  To me (unfamiliar with the systemd code) 
> > those two functions seem distinct enough to merit being separate.  Debian 
> > can't easily separate what the systemd devs have developed as a single 
> > binary, so we end up with these strange dependency chains.
> 
> "Single binary" is false of course. Logind is developed as a separate
> program, which is why systemd-shim is possible at all.
> 
> AFAIK the actual relevant dependencies go as follows: First, there's a
> good reason why logind requires cgroup functionality. And there's a good
> reason why cgroup functionality is best implemented together with init
> (see
> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> for more info). So it's not quite directly "logind has to depend on
> systemd as init", but "logind has to depend on the system having cgroup
> support, and there's no equally good cgroup support available for inits
> other than systemd". It is possible to provide the relevant cgroup
> interfaces in or on top of another init, as the systemd-sysv + cgmanager
> combination attempts to do. But it is not trivial to do, as bugs and
> implementation delays with that combo have shown, and it's quite likely
> that there will be more problems in the future. It's not a particularly
> good idea to use the less-tested and less-reliable systemd-shim instead
> of the more reliable systemd. Thus the overall result is that yes, it
> does make sense to switch machines to systemd when you add certain
> functionality, even if that functionality does not appear to be directly
> tied to the init system at first glance.

Also note that the systemd concepts logind makes use of are also
exported in its own API. The "scopes" and "slices" that logind uses
are exposed on its bus objects, and they are used by tools like
"loginctl" to do their work.

The "scopes" and "slices" concept does not exist elsewhere, and
there's nothing comparable around, so even if we wanted we couldn't
make logind work on anything else.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Uoti Urpala]

On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote:
> My question really isn't "why are the Debian dependencies the way they are".  
> I understand that.  I was trying to highlight the strange situation of a 
> desktop application requiring a particular init system.  I *think* this is a 
> result of the init portion of systemd being bundled together with the logind 
> portion of systemd.  To me (unfamiliar with the systemd code) those two 
> functions seem distinct enough to merit being separate.  Debian can't easily 
> separate what the systemd devs have developed as a single binary, so we end 
> up with these strange dependency chains.

"Single binary" is false of course. Logind is developed as a separate
program, which is why systemd-shim is possible at all.

AFAIK the actual relevant dependencies go as follows: First, there's a
good reason why logind requires cgroup functionality. And there's a good
reason why cgroup functionality is best implemented together with init
(see
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
for more info). So it's not quite directly "logind has to depend on
systemd as init", but "logind has to depend on the system having cgroup
support, and there's no equally good cgroup support available for inits
other than systemd". It is possible to provide the relevant cgroup
interfaces in or on top of another init, as the systemd-sysv + cgmanager
combination attempts to do. But it is not trivial to do, as bugs and
implementation delays with that combo have shown, and it's quite likely
that there will be more problems in the future. It's not a particularly
good idea to use the less-tested and less-reliable systemd-shim instead
of the more reliable systemd. Thus the overall result is that yes, it
does make sense to switch machines to systemd when you add certain
functionality, even if that functionality does not appear to be directly
tied to the init system at first glance.


> I never thought much about my init system until recently.  I never really had 
> any complaints with SysV init, although I do recognize that systemd provides 
> real improvements for some use cases.  So for me as a sysadmin the wisest 
> thing to do is stick with what I already know, as long as it's working well 
> enough (and for me, it is).

The issue with "I should be able to stay with sysvinit because it worked
fine for me" is that keeping sysvinit working is COSTLY. The reason
sysvinit used to mostly work was not that it would have been a reliable
system - it mostly worked because people kept using a lot of effort to
work around and paper over various issues that kept popping up. And
there's no justification to keep up that effort for the minority who
wants to stay with sysvinit. So, you can keep running your old systems
unchanged if you want, but you shouldn't expect to be able to upgrade
them or install new software without switching to systemd.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek" 
> On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote:

> > On Debian, I came across an unusual dependency.  Installing a cd burner
> > (brasero) required me to change my init system to systemd.  Sounds kind of
> > ridiculous, I think.  The dependency chain went like this:
> > 
> > brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd ->
> > systemd-sysv
> > 
> > I don't know enough about this stuff to comment very intelligently, which
> > is why I haven't said anything up until now.  But my research shows that
> > each of these dependencies is indeed valid in the sense that each
> > dependency represents some real requirement for functionality.  The issue,
> > I think, is that some of these packages provide very broad functionality.
> > As I put it in a Debian bug report:
> > 
> > Brasero needs X functionality, which can be found in package W.  Package W
> > also provides Y functionality, which depends on systemd-sysv.  So
> > therefore brasero depends on systemd-sysv, even though it doesn't *need*
> > it.
> > 
> > I gather that this has something to do with logind and/or cgroups.  I can
> > appreciate the benefits (on some systems) of giving only the local user
> > access to removable media.  But I don't understand why this functionality
> > requires the use of systemd-sysv (the init system), particularly if my
> > understanding is correct that this functionality used to be separate from
> > the init portion of systemd.
> 
> I'll assume that this is a serious question, despite being rather
> elementary...

My question really isn't "why are the Debian dependencies the way they are".  I 
understand that.  I was trying to highlight the strange situation of a desktop 
application requiring a particular init system.  I *think* this is a result of 
the init portion of systemd being bundled together with the logind portion of 
systemd.  To me (unfamiliar with the systemd code) those two functions seem 
distinct enough to merit being separate.  Debian can't easily separate what the 
systemd devs have developed as a single binary, so we end up with these strange 
dependency chains.

I am trying to demonstrate the drawbacks of the decision to combine logind with 
the init portion of systemd.  I'm giving you an outsider's point of view.  I 
realize that most of the folks on this list probably love all of systemd and 
couldn't imagine why anyone would want to have just bits and pieces of it.  But 
I think my previous email gave some good reasons.  If not, let me know and I'll 
try to be more clear about it.

> The second option requires someone to step up and provide an
> alternative implementation. So far, systemd-shim is one candidate, but
> it took months to appear and still has occasional problems. (I don't
> follow the situation quite closely, but Michael seems to find serious
> bugs with very light testing). At some point, systemd-shim might
> become a viable replacement. This work should be done by people who
> want the alternatives, not the maintainers of systemd, who happily use
> the existing stack. So if the alternatives are not in the shape you
> would like them to be, inquire with the maintainers of the said
> alternatives.
> 
> But even assuming that an alternative is functional, using it is not
> without costs for the maintainers of dependent packages. Let's say
> that we have some systems with systemd, some with systemd-shim. It is
> likely that a bug report for udisk2 might require the maintainer to
> ask which of the alternatives is used. For such basic functionality
> that influences the whole OS, if the maintainer uses a different
> init, it is like being on a different architecture. It makes things
> hard to debug, hard to test, and greatly distracts from the time
> the maintainer has available to really fix bugs. It is not free, and
> diminishes the appeal of the whole distribution. It might be that
> this alternative dependency has advantages which outweigh this cost.

I think everything you said in these two paragraphs could be used to support 
the argument of keeping logind separate from init.  Then everybody would be 
using your logind code, and there would be no need for systemd-shim.  There 
still would be the issue for package maintainers of supporting multiple init 
systems, but that's Debian's decision to do so.

> But seriously, is SysV init that great?

I never thought much about my init system until recently.  I never really had 
any complaints with SysV init, although I do recognize that systemd provides 
real improvements for some use cases.  So for me as a sysadmin the wisest thing 
to do is stick with what I already know, as long as it's working well enough 
(and for me, it is).

> > Systemd-shim provides some functionality that systemd-sysv provides,
>   and allows admins to use init systems other than systemd while still
>   installing things like brasero.  I think this is a great thing,
>   excep

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 02:56:22PM -0400, Rob Owens wrote:
> - Original Message -
> > From: "Martin Steigerwald" 
> 
> > Heck, I started a thread here and then didn´t manage to take time to
> > carefully
> > read it and reply here and there as I see fit. But I challenged people on
> > debian-user mailing list to constructively voice their concerns upstream, 
> > and
> > even pointed them to this mailing list. As far as I saw *no one* of the
> > posters in debian-user took up on that challenge. Which I view as a pity.
> > Cause now actually you invited constructive feedback. I wonder whether I may
> > forward your answer to debian-user so they see your statement of inviting
> > constructive feedback.
>  
> I am here from debian-user, due to Martin's suggestion.  So now that he's 
> calling me out, I guess I'll post my questions :)
> 
> For the record, I'm a sysadmin and not a developer.  I imagine my questions 
> and opinions will reflect that.
> 
> > Here the feedback I read over and over again is that you and RedHat 
> > basically
> > forced the systemd decision onto other distributions. While I do not see how
> > you actually can be powerful enough to do that, as we live in a free will
> > zone. I do see tendencies that more and more stuff *depends* on systemd 
> > cause
> > it needs features only available there.
> > 
> > On of the most talked on things on debian-user is the logind thing. GNOME
> > actually depends on it, as far as I know. While KDE in Debian still uses
> > ConsoleKit, as it seems to me when looking at the process list and finding:
> 
> On Debian, I came across an unusual dependency.  Installing a cd burner 
> (brasero) required me to change my init system to systemd.  Sounds kind of 
> ridiculous, I think.  The dependency chain went like this:
> 
> brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv 
> 
> I don't know enough about this stuff to comment very intelligently, which is 
> why I haven't said anything up until now.  But my research shows that each of 
> these dependencies is indeed valid in the sense that each dependency 
> represents some real requirement for functionality.  The issue, I think, is 
> that some of these packages provide very broad functionality.  As I put it in 
> a Debian bug report:
> 
> Brasero needs X functionality, which can be found in package W.  Package W 
> also provides Y functionality, which depends on systemd-sysv.  So therefore 
> brasero depends on systemd-sysv, even though it doesn't *need* it.
> 
> I gather that this has something to do with logind and/or cgroups.  I can 
> appreciate the benefits (on some systems) of giving only the local user 
> access to removable media.  But I don't understand why this functionality 
> requires the use of systemd-sysv (the init system), particularly if my 
> understanding is correct that this functionality used to be separate from the 
> init portion of systemd.

I'll assume that this is a serious question, despite being rather
elementary...

You describe a dependency chain. First of all, it is important to note
that it does not matter if brasero actually uses the part of gvfs that
uses the part of udisk2 that uses the part of libpam-systemd that
requires systemd to be running. Possibly not, and maybe brasero would
still function correctly w/o systemd. But dependencies are expressed
on package level, so if systemd is required for some functionality of
libpam-systemd, which is used by any package depending on
libpam-systemd, then libpam-systemd must depend on systemd-sysv, and
transitively so must brasero.

To break this chain at some point, it is necessary replace the strict
dependency with "recommends/suggests" or provide a different different
package which satisfies the dependency. The first option is only
possible if the functionality provided by the dependent package
is not essential. In some cases it is really clear, e.g. a binary
requires a library to be installed to be able to run, but in
other cases it's a judgment call by the maintainers, whether some
part of functionality is important enough to add a dependency.
In this case brasero, gvfs, udisks2, and systemd maintainers decided
that yes, it is.

The second option requires someone to step up and provide an
alternative implementation. So far, systemd-shim is one candidate, but
it took months to appear and still has occasional problems. (I don't
follow the situation quite closely, but Michael seems to find serious
bugs with very light testing). At some point, systemd-shim might
become a viable replacement. This work should be done by people who
want the alternatives, not the maintainers of systemd, who happily use
the existing stack. So if the alternatives are not in the shape you
would like them to be, inquire with the maintainers of the said
alternatives.

But even assuming that an alternative is functional, using it is not
without costs for the maintainers of dependent packages. Let's say
that we have some syste

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Pitt]

Hello Rob,

this is higly Debian specific (doesn't even apply to Ubuntu) and thus
a bit off-topic, but as the question already is on the upstream ML..
sorry!

Rob Owens [2014-10-06 14:56 -0400]:
> brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv 

You can break it up after libpam-systemd, as this has dependency
alternatives to systemd-shim. With that you can use sysvinit or
upstart. But currently systemd-sysv is the preferred alternative, so
if you don't specify anything else it will pick systemd-sysv. You can
do e. g. "apt-get install brasero systemd-shim" to select another (or
install -shim first).

> I gather that this has something to do with logind and/or cgroups.

That's correct; in fact most desktop-y software talks to logind
only, but logind is a crucial component on a modern desktop.

> Systemd-shim is a duplication of effort.

It's a looong story/history, but systemd-shim itself is actually
fairly small. It's mostly glue to provide systemd's D-BUS API and
implement it in terms of other components like cgmanager and pm-utils.
And its development was quite inevitable at least from
Debian's/Ubuntu's perspective as it is just practically impossible to
do a SysV/upstart → systemd migration on a flag day.

> Not only that, but it must time its releases with the releases of
> systemd-sysv.

Mostly not. That needs to happen for D-BUS API changes like they
happened around version 209, but that happens fairly seldomly.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Rob Owens]

- Original Message -
> From: "Martin Steigerwald" 

> Heck, I started a thread here and then didn´t manage to take time to
> carefully
> read it and reply here and there as I see fit. But I challenged people on
> debian-user mailing list to constructively voice their concerns upstream, and
> even pointed them to this mailing list. As far as I saw *no one* of the
> posters in debian-user took up on that challenge. Which I view as a pity.
> Cause now actually you invited constructive feedback. I wonder whether I may
> forward your answer to debian-user so they see your statement of inviting
> constructive feedback.
 
I am here from debian-user, due to Martin's suggestion.  So now that he's 
calling me out, I guess I'll post my questions :)

For the record, I'm a sysadmin and not a developer.  I imagine my questions and 
opinions will reflect that.

> Here the feedback I read over and over again is that you and RedHat basically
> forced the systemd decision onto other distributions. While I do not see how
> you actually can be powerful enough to do that, as we live in a free will
> zone. I do see tendencies that more and more stuff *depends* on systemd cause
> it needs features only available there.
> 
> On of the most talked on things on debian-user is the logind thing. GNOME
> actually depends on it, as far as I know. While KDE in Debian still uses
> ConsoleKit, as it seems to me when looking at the process list and finding:

On Debian, I came across an unusual dependency.  Installing a cd burner 
(brasero) required me to change my init system to systemd.  Sounds kind of 
ridiculous, I think.  The dependency chain went like this:

brasero -> gvfs -> gvfs-daemons -> udisks2 -> libpam-systemd -> systemd-sysv 

I don't know enough about this stuff to comment very intelligently, which is 
why I haven't said anything up until now.  But my research shows that each of 
these dependencies is indeed valid in the sense that each dependency represents 
some real requirement for functionality.  The issue, I think, is that some of 
these packages provide very broad functionality.  As I put it in a Debian bug 
report:

Brasero needs X functionality, which can be found in package W.  Package W also 
provides Y functionality, which depends on systemd-sysv.  So therefore brasero 
depends on systemd-sysv, even though it doesn't *need* it.

I gather that this has something to do with logind and/or cgroups.  I can 
appreciate the benefits (on some systems) of giving only the local user access 
to removable media.  But I don't understand why this functionality requires the 
use of systemd-sysv (the init system), particularly if my understanding is 
correct that this functionality used to be separate from the init portion of 
systemd.

> Dependencies like this actually create some force to adopt systemd.

Based on Lennart's and others' comments in this thread, forced adoption does 
not seem to be a goal.  But forced adoption is a reality due to dependencies 
like the one above.  I think there would be a lot less skepticism about systemd 
if the perception of forced adoption weren't so strong, and I'd love to see 
something done about this situation.

> Now I know ConsoleKit isn´t developed anymore, but also I never got why a
> logind implementation needs to depend on systemd base package in such a way
> that at least in Debian systemd package has to be installed if someone wants
> to use GNOME.

Is this what Debian's systemd-shim is for?  If not, well I'm going to talk 
about that anyway...

Systemd-shim provides some functionality that systemd-sysv provides, and allows 
admins to use init systems other than systemd while still installing things 
like brasero.  I think this is a great thing, except I wonder why the systemd 
project didn't separate this functionality from the init system in the first 
place.  Systemd-shim is a duplication of effort.  Not only that, but it must 
time its releases with the releases of systemd-sysv.  That's no big deal for 
Debian's stable release, but it can be problematic in Debian's unstable and 
testing branches.

Wouldn't the systemd developers prefer to have their implementation of this 
functionality be used, regardless of the chosen init system?

> > Let me stress this: constructive feedback is *always* welcome!

The following may not concern you personally, but Debian is attempting to 
support multiple kernels (Linux, BSD and Hurd I think).  As I understand it, 
systemd is Linux-only.  Defaulting to a Linux-only init system makes supporting 
non-Linux kernels more work, because an alternate init system must be 
maintained, as well as init scripts for that init system.  If functionality was 
separated as I described above, and the systemd project provided a very basic 
init-only package, would that be portable to non-Linux kernels?

> Users can also decide to help test the alternatives. Unlike other distros
> Debian still supports them.

But systemd's approach of incorporating additi

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 05:14:17PM +0200, Lennart Poettering wrote:
> On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote:
> > > > systemd does a lot. And an 1,3 MiB binary is a hug binary size for 
> > > > something 
> > > > that started out as managing services and sessions via control
> > > > cgroups.
> > > 
> > > Well, it does a lot more these days. 
> > > 
> > > The Linux kernel also started out pretty small too. Nowadays it does a
> > > lot more, which makes it so unversially applicable. I figure systemd
> > > goes a similar path. (Though hopefully will never grow as massive,
> > > complex and monolithic as the kernel...)
> > This is an interesting question, where this 1.3 MB comes from.
> > 
> > objdump -t ./systemd|sed -r -n 
> > 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ 
> > \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail
> > 
> > 0a13 service_deserialize_item -- .text
> > 0a6e cgroup_context_apply -- .text
> > 0ae2 socket_apply_socket_options -- .text
> > 0b00 rtnl_types -- .data.rel.ro.local
> > 0b32 exec_context_dump -- .text
> > 0d50 bus_exec_vtable -- .data.rel.ro
> > 0d62 transaction_add_job_and_dependencies -- .text
> > 0e40 bus_unit_vtable -- .data.rel.ro
> > 11d7 bus_cgroup_set_property -- .text
> > 1410 bus_manager_vtable -- .data.rel.ro
> > 1453 exec_child -- .text
> > 1470 wordlist.7848 -- .data.rel.ro.local
> > 2b90 main -- .text
> > e1c0 wordlist.14097 -- .data.rel.ro
> > 
> > wordlist.14097 is a generated table for all configuration options in
> > load-fragment-gperf.c.
> > 
> > wordlist.7848 is for errno_from_name (5k for this is a bit of a
> > stretch though).
> 
> I wonder if any of these tables might have holes in them? i.e. some
> enums skip a few numbers in the middle, and are thus not really
> appropriate for the usual DEFINE_STRING_TABLE() stuff we do?
I think it's like a hash table, i.e. approx %50 empty on purpose.

At least in case load load-fragment-gperf, we are trading a bit of
space for speed in an important code path, so I'm sure it is worth
it. The errno stuff isn't probably that important, because iiuc we
won't even load this page until it is used, so again, this seems fine.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote:
> > > systemd does a lot. And an 1,3 MiB binary is a hug binary size for 
> > > something 
> > > that started out as managing services and sessions via control
> > > cgroups.
> > 
> > Well, it does a lot more these days. 
> > 
> > The Linux kernel also started out pretty small too. Nowadays it does a
> > lot more, which makes it so unversially applicable. I figure systemd
> > goes a similar path. (Though hopefully will never grow as massive,
> > complex and monolithic as the kernel...)
> This is an interesting question, where this 1.3 MB comes from.
> 
> objdump -t ./systemd|sed -r -n 
> 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ 
> \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail
> 
> 0a13 service_deserialize_item -- .text
> 0a6e cgroup_context_apply -- .text
> 0ae2 socket_apply_socket_options -- .text
> 0b00 rtnl_types -- .data.rel.ro.local
> 0b32 exec_context_dump -- .text
> 0d50 bus_exec_vtable -- .data.rel.ro
> 0d62 transaction_add_job_and_dependencies -- .text
> 0e40 bus_unit_vtable -- .data.rel.ro
> 11d7 bus_cgroup_set_property -- .text
> 1410 bus_manager_vtable -- .data.rel.ro
> 1453 exec_child -- .text
> 1470 wordlist.7848 -- .data.rel.ro.local
> 2b90 main -- .text
> e1c0 wordlist.14097 -- .data.rel.ro
> 
> wordlist.14097 is a generated table for all configuration options in
> load-fragment-gperf.c.
> 
> wordlist.7848 is for errno_from_name (5k for this is a bit of a
> stretch though).

I wonder if any of these tables might have holes in them? i.e. some
enums skip a few numbers in the middle, and are thus not really
appropriate for the usual DEFINE_STRING_TABLE() stuff we do?

> I think this hasn't been mentioned in this thread, but PID1 is
> shrinking at least a bit, because a bunch of things which used to be
> implemented in PID1 have been outsourced to generators.
> ./systemd-sysv-generator, ./systemd-fstab-generator are relatively
> recent and significant.

And I'd be willing to split out more, but I am not sure currently what
could be a good candidate.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote:
> > systemd does a lot. And an 1,3 MiB binary is a hug binary size for 
> > something 
> > that started out as managing services and sessions via control
> > cgroups.
> 
> Well, it does a lot more these days. 
> 
> The Linux kernel also started out pretty small too. Nowadays it does a
> lot more, which makes it so unversially applicable. I figure systemd
> goes a similar path. (Though hopefully will never grow as massive,
> complex and monolithic as the kernel...)
This is an interesting question, where this 1.3 MB comes from.

objdump -t ./systemd|sed -r -n 
's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ 
\t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail

0a13 service_deserialize_item -- .text
0a6e cgroup_context_apply -- .text
0ae2 socket_apply_socket_options -- .text
0b00 rtnl_types -- .data.rel.ro.local
0b32 exec_context_dump -- .text
0d50 bus_exec_vtable -- .data.rel.ro
0d62 transaction_add_job_and_dependencies -- .text
0e40 bus_unit_vtable -- .data.rel.ro
11d7 bus_cgroup_set_property -- .text
1410 bus_manager_vtable -- .data.rel.ro
1453 exec_child -- .text
1470 wordlist.7848 -- .data.rel.ro.local
2b90 main -- .text
e1c0 wordlist.14097 -- .data.rel.ro

wordlist.14097 is a generated table for all configuration options in
load-fragment-gperf.c.

wordlist.7848 is for errno_from_name (5k for this is a bit of a
stretch though).

There's pretty complex code (main is 11k), combined with a large
number of configuration and reporting code (the wordlists, vtables,
exec_context_dump).

This shows that splitting the binary into two would not be really
effective: this code would essentially have to be duplicated, once for
communication between PID 1 and the helper, and second time for
communication between the helpers and the rest, i.e. the existing code.

--

I think this hasn't been mentioned in this thread, but PID1 is
shrinking at least a bit, because a bunch of things which used to be
implemented in PID1 have been outsourced to generators.
./systemd-sysv-generator, ./systemd-fstab-generator are relatively
recent and significant.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Sun, 05.10.14 12:20, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> > However, I also believe that the change we are making is for the good,
> > and even though it might not be obvious to many immediately, it brings
> > major benefits when administering machines, and they massively
> > outweigh the disadvantage of changing things. And apparently I am not
> > entirely alone with this, as the folks who make technical decision for
> > the various distributions ended up deciding in favour of systemd in
> > most cases.
> 
> Why do you believe so? What key points make you believe so?

Believe what precisely? Why I believe systemd is better than sysvinit?
Well, that's a big question, and I am pretty sure already well enough
discussed elsewhere, that we really do't have to repeat this here.

> Here the feedback I read over and over again is that you and RedHat basically 
> forced the systemd decision onto other distributions. While I do not see how 
> you actually can be powerful enough to do that, as we live in a free will 
> zone. I do see tendencies that more and more stuff *depends* on systemd cause 
> it needs features only available there.

Well, we provide good APIs. We provide them for a reason, because
applications benefit from them. App developers see that, so they adopt
them. That's pretty natural and obvious, no? If you want to know more,
about why they do that, then ask them.

What I find so puzzling about certain aspects of the criticism is that
some people apparently assume that logind and similar things were
entirely redundant, and that the APIs that it provides were so
redundant, that one could trivially write the same app, but not make
use of them... This idea that logind had exactly no merits, and was
little more than just an evil tool to drive systemd adoption...

> Dependencies like this actually create some force to adopt systemd.

Well, I certainly don't force anybody. We provide APIs for technical
reasons, and because we believe that people might benefit from them,
even need them. And apparently I am not too wrong with that, after all
they tend to adopt them...

> Now I know ConsoleKit isn´t developed anymore, but also I never got why a 
> logind implementation needs to depend on systemd base package in such a way 
> that at least in Debian systemd package has to be installed if someone wants 
> to use GNOME.

Well, logind talks to systemd to manage user sessions and user
processes in cgroups. That's why it depends on systemd. And since only
systemd implements that, we couldn't even support anything else even
if we wanted.

Our intention with systemd is to provide a strong platform. One
platform. If people want to use our code in other contexts, then
that's totally fine, but please understand that I am not going to do
any work for that, I am not going to maintain it, and I don't want to
see that in my code. 

> Much of the feedback is related to that. Many would appreciate something like 
> systemd if it just did *services* stuff. That is also what seemed to have 
> motivated the dev behind the use less d fork.

Well, I am sorry, but systemd is more than that. If systemd is no what
people want, they can roll their own thing, can continue to use
sysvinit, or even fork systemd, That's completely OK. But for what we
have in mind for systemd it's definitely a goal to make Linux more
attractive for developers, by providing a good set of core OS APIs
that people can just make use of, instead of a zoo of things that are
combined in wild combinations.

> > The current increase noised level around systemd adoption I attribute
> > to three things: the fact that RHEL7 is out now, the fact that due to
> > the adoption of systemd as default by Debian and Ubuntu the folks who
> > ignored the discussion so far now are faced with this change, and also
> > to a big part to certain "columnists" who in the interest of
> > generating traffic to their sites try to create a hubbub out of very
> > little.
> > 
> > Anyway, long story short: we knew what we did, and yeah, I read
> > feedback, even if it is written in a hateful style, and we learn from
> > it.
> 
> Well, I for myself have been concerned and surprised by *such an mount* of 
> uproar. Not even GNOME 3 triggered anywhere near that amount of threads and 
> mails.

Well, I am not sure this is really that way. GNOME 3 noise was pretty bad too,
maybe you just weren't involved so closely... But even if it wasn't,
our stuff touches most of the Linux community, which is larger than
the GNOME community.

> And I worry regarding various attempts to replace systemd functionality (by 
> systembsd services) and by use less d or using different inits. I think quite 
> some of them are based on solid technical arguments. I wonder whether systemd 
> might be missing out on something here.

Well, some competition would be great. I am pretty sure that uselessd
is not based on solid technical arguments though, and pretty sure
it's maintainer will figure that out 

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Hi Jóhann,

Am Sonntag, 21. September 2014, 22:15:32 schrieb Jóhann B. Guðmundsson:
> On 09/21/2014 01:31 PM, Martin Steigerwald wrote:
> > in the light of the ongoing discussions on linux-kernel
> 
> Could you provide a link to that ongoing discussion that is taking place
> in the kernel community regarding systemd?

I think this is the one I meant:

OT: Open letter to the Linux World
https://lkml.org/lkml/2014/8/12/459

It seems to have ceased meanwhile.

Also on some other occasion a kernel developer agreed on my concerns regarding 
binary size of PID 1 with systemd.

> > Did you ever ask yourself why your project provokes that amount of
> > resistance and polarity? Did you ever ask yourself whether this really is
> > just resistance against anything new from people who just do not like
> > "new" or whether it contains*valuable*  and*important*  feedback?
> 
> I'm not sure why you are under the assumption that we do not consider
> and have not and are not gathering feedback from individuals,
> communities or companies for that matter but I'm going to address your
> questions anyway.
> 
> Have we ever asked ourselves why our project provokes that amount of
> resistance and polarity?
> 
> The answer to that question is yes, yes we have and yes we will continue
> to do so since resistance and polarity provides with the valuable
> information amongst other things if the implementation is bad and
> alternative approach is better ( which often reveals itself at the same
> time those friction take place ).
> 
> Dont get me wrong we will not do so when those discussion involve
> nothing but personal attack on our community member(s) which more often
> than not happens to be Lennart, Lennart is and never has been the sole
> person behind this effort, he's part of ever growing community.

I am not willing to tolerate personal attacks on Debian user. I just 
remembered that I can act on it and filed an abuse complaint about some of 
those.

> Nor when it involves us having to implement somekind of hack as opposed
> to have the problem properly fixed where it belongs ( which could be us
> or not ) or when those discussion criticizes that we have chosen to
> tightly integrate ourselves specifically to the linux kernel it's
> ecosystem and with glibc in mind just like bsd based distribution as
> well as solaris and other nixes are tightly integrating their components
> to their kernels but for some dumbfound reason people on the internet
> are under the assumption that they have the authority of refusing us the
> freedom of doing the same o_O and the answer to those individuals we
> dont care about their opinion on this matter.
> 
> Now alot of the resistance and polarity that is taking place like in the
> url you pointed at is hiding itself behind their misinterpretation of
> the so called "Unix philosophy" and claiming that we somehow fall short
> on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken
> Thompson said sometime in the 70's or rather the "Unix philosophy" was
> implied not by what these individuals said but rather by what they did
> which more or less boils down to this..
> 
> 1. Write simple parts connected by clean interfaces.

Well, I for one wonder what is all in that 1,3 MiB binary of systemd running 
as PID 1? In my estimation it can´t be just some services handling and control 
groups management. As that would be much smaller I believe. There is systemd 
--user running just a fraction of code of this binary as Lennart explained.

To me, this is a huge binary and to me its not clear what things it does and 
how they operate with one another via a clean interface if packed all into one 
binary.

> 2. Clarity is better than cleverness.

Using debug commands was needed to diagnose a fstab syntax error:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25

As I pointed out (with wrong bug link, sorry).

Its arguable whether to fail hard on syntax errors in fstab, but if systemd 
fails hard, I expect put me a *big fat* error message on the screen explaining 
the issue at hand. Except expecting me to use debug commands to find out whats 
wrong.

> 3. Design programs to be connected to other programs.

Well we appear to have quite some binaries. But according to binary size, very 
much of the functionality appears to be in systemd main binary. But even other 
binaries are quite large for what they do.

merkaba:~> ( for FILE in $( dpkg -L systemd | egrep "lib|bin" ); do test -f 
"$FILE" && test -x "$FILE" && stat --format "%s %n" "$FILE" ; done ) | sort -
rn
1309064 /lib/systemd/systemd
538904 /bin/systemctl
522480 /lib/systemd/systemd-networkd
506096 /lib/systemd/systemd-logind
366856 /usr/bin/systemd-nspawn
325872 /lib/systemd/systemd-machined
309488 /bin/loginctl
297192 /lib/systemd/systemd-localed
293096 /lib/systemd/systemd-timedated
289000 /lib/systemd/systemd-hostnamed
288992 /lib/systemd/systemd-bus-proxyd
280816 /bin/machinectl
276712 /usr/bin/busctl
272616 /usr/bin/syst

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Mittwoch, 1. Oktober 2014, 23:33:43 schrieb Lennart Poettering:
> (What I didn't expect though is how awful the Linux community can
> actually be. That people collect Bitcoins to hire a hitman on me, that
> people start petitions to make me stop working, and all that other
> really hateful, personal stuff is really apalling. I guess I have a
> thick skin, because I don't care too much, but jeezus christ, it's
> really disgusting sometimes.)

I just filed an abuse complaint about some personal attacks to you and systemd 
supporters in general with Debian listmasters. They were way out of bounds of 
netiquette. I am not willing to tolerate such abuse.

Also went to LKML, but I am not aware of any netiquette reporting for it.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Sonntag, 5. Oktober 2014, 12:20:01 schrieb Martin Steigerwald:
> Well… I may post much more in this thread.

not post much more

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Hi Lennart,

Am Mittwoch, 1. Oktober 2014, 23:33:43 schrieb Lennart Poettering:
> On Sun, 21.09.14 15:31, Martin Steigerwald (mar...@lichtvoll.de) wrote:
> > I just have one question. In the light of
> 
> [...]

Heck, I started a thread here and then didn´t manage to take time to carefully 
read it and reply here and there as I see fit. But I challenged people on 
debian-user mailing list to constructively voice their concerns upstream, and 
even pointed them to this mailing list. As far as I saw *no one* of the 
posters in debian-user took up on that challenge. Which I view as a pity. 
Cause now actually you invited constructive feedback. I wonder whether I may 
forward your answer to debian-user so they see your statement of inviting 
constructive feedback.

> > in the light of the ongoing discussions on linux-kernel, debian-devel,
> > debian- user and other mailing lists more than some dozens threads
> > meanwhile:
> > 
> > Did you ever ask yourself why your project provokes that amount of
> > resistance and polarity? Did you ever ask yourself whether this really is
> > just resistance against anything new from people who just do not like
> > "new" or whether it contains *valuable* and *important* feedback?
> 
> That's already two questions...
> 
> But anyway. Let me turn your question around: we swapped out one of
> the most central pieces of Linux systems, one of the pieces that is
> probably the most core of what administrators interface with every
> day. How could this change ever have gone *without* any noise?

Yet… I think it is not just noise.

> Administrators probably are a generally more conservative bunch,
> anything that interferes with their day-to-day workflow that they are
> used to is a distraction. That's quite understandable. In fact, I used
> to be an admin myself a long time ago, and I still administer a couple
> of machines. I have similar feelings when I update them, and in
> particular when some component I don't want to spend the time to relearn
> changes I end up being annoyed (dovecot config file changes!).

Oh, I know this one. I moved all the gazillion config files away and told it to 
use my old single file config. And for my setup using a ton of config files 
just 
adds immensively to my maintenance overheard, when I can write down the 
configuration in a page of text.

> Moreover, init systems are just an auxiliary tool to run
> things. Nobody starts a computer up to run systemd on it. People start
> up a computer to run a web app or database server software on
> it. Because of that, systemd is just a tool to make something else
> work, and the focus is always on that other thing, and any time spent
> on systemd or relearning it feels like wasted time to many. I totally
> and absolutely understand these feelings.

Well I do see advantages. I am one of the early adopters of systemd. And I 
would need to hold hands before my eyes to not see the advantages. But I can 
also resonate with some of the concerns.

> However, I also believe that the change we are making is for the good,
> and even though it might not be obvious to many immediately, it brings
> major benefits when administering machines, and they massively
> outweigh the disadvantage of changing things. And apparently I am not
> entirely alone with this, as the folks who make technical decision for
> the various distributions ended up deciding in favour of systemd in
> most cases.

Why do you believe so? What key points make you believe so?

Here the feedback I read over and over again is that you and RedHat basically 
forced the systemd decision onto other distributions. While I do not see how 
you actually can be powerful enough to do that, as we live in a free will 
zone. I do see tendencies that more and more stuff *depends* on systemd cause 
it needs features only available there.

On of the most talked on things on debian-user is the logind thing. GNOME 
actually depends on it, as far as I know. While KDE in Debian still uses 
ConsoleKit, as it seems to me when looking at the process list and finding:

/usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session 
/usr/bin/startkde

Dependencies like this actually create some force to adopt systemd.

Now I know ConsoleKit isn´t developed anymore, but also I never got why a 
logind implementation needs to depend on systemd base package in such a way 
that at least in Debian systemd package has to be installed if someone wants 
to use GNOME.

Also some parts of KDE seem to depend on systemd meanwhile in Debian – 
basically udisks related parts and Network-Manager:

merkaba:~> LANG=C apt-get purge systemd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  amor analitza-common blinken cantor cantor-backend-kalgebra
  filelight kaccessible kalgebra kalgebra-common kalzium
  kalzium-data kanagram kbruch kcharselect kcolorchooser
  kde

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Tue, 23.09.14 15:13, Dale R. Worley (wor...@alum.mit.edu) wrote:

> > Again, this seems rather ignorant of the status quo. Between the blog
> > posts and wiki documentation and the 164 man pages, systemd is rather
> > copiously documented. Not to say that things can't be improved, but
> > by Linux standards we are at least making an effort. Bugs for missing
> > or unclear documentation and usually handled, and any patches for
> > documentation are applied fairly quickly.
> 
> OK, I'd like to modify systemd's handling of mounts.  I've been told
> only that the units that are created from /etc/fstab are created and
> handled by the main systemd binary.  What documentation do I look at
> that explains how systemd actually does that, what the relevant source
> is, etc.?  With init scripts, I know it's somewhere in a script in
> /etc/rc.d/init.d; searching for "mount" probably reveals a couple of
> hundred lines of shell script within which the functionality is
> hiding.

As mentioned on this thread "systemctl help" on a unit is a really
easy way to get more information about it. Pretty much all units we
ship with systemd upstream contains the necessary meta information to
link it up directly with its docs.

mount units for /etc/fstab entries are nowadays generated from a so
called "generator", see systemd-fstab-generator(8).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Mon, 22.09.14 10:16, Dale R. Worley (wor...@alum.mit.edu) wrote:

> 1. Systemd has some very large binaries, each of which implements many
> aspects of the system.  Conversely, the typical Un*x approach is to
> separate functions into many executablels, many of which are scripts.
> The latter approach makes customization easier, especially for
> sysadmins who aren't deeply familiar with the system.

We split up things into 80+ binaries. 

> 2. Systemd includes a tremendous number of features and behaviors, but
> a lot of them aren't documented very well.  That's not so unusual in
> Un*x, but if you're introducing something new, nobody has any prior
> knowledge of it, and the lack of documentation becomes visible.

Please let us know where documentation is missing. I know a couple of
areas where documentation is lacking (such as the too muc hof the C
APIs we expose currently), but at least the user-facing stuff should
be pretty comprehesively documented. If you are missing docs for
something I'd be quite interested to know for which parts so that we
can actually fix it.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Lennart Poettering]

On Sun, 21.09.14 15:31, Martin Steigerwald (mar...@lichtvoll.de) wrote:

> I just have one question. In the light of

[...]
> 
> in the light of the ongoing discussions on linux-kernel, debian-devel, debian-
> user and other mailing lists more than some dozens threads meanwhile:
> 
> Did you ever ask yourself why your project provokes that amount of resistance 
> and polarity? Did you ever ask yourself whether this really is just 
> resistance 
> against anything new from people who just do not like "new" or whether it 
> contains *valuable* and *important* feedback?

That's already two questions...

But anyway. Let me turn your question around: we swapped out one of
the most central pieces of Linux systems, one of the pieces that is
probably the most core of what administrators interface with every
day. How could this change ever have gone *without* any noise?

Administrators probably are a generally more conservative bunch,
anything that interferes with their day-to-day workflow that they are
used to is a distraction. That's quite understandable. In fact, I used
to be an admin myself a long time ago, and I still administer a couple
of machines. I have similar feelings when I update them, and in
particular when some component I don't want to spend the time to relearn
changes I end up being annoyed (dovecot config file changes!).

Moreover, init systems are just an auxiliary tool to run
things. Nobody starts a computer up to run systemd on it. People start
up a computer to run a web app or database server software on
it. Because of that, systemd is just a tool to make something else
work, and the focus is always on that other thing, and any time spent
on systemd or relearning it feels like wasted time to many. I totally
and absolutely understand these feelings.

However, I also believe that the change we are making is for the good,
and even though it might not be obvious to many immediately, it brings
major benefits when administering machines, and they massively
outweigh the disadvantage of changing things. And apparently I am not
entirely alone with this, as the folks who make technical decision for
the various distributions ended up deciding in favour of systemd in
most cases.

Yes, we knew exactly we'd be getting a lot of heat for all this. We
have been getting it from the day on we announced the project. And I
am pretty sure it will continue this way for a while still. 

(What I didn't expect though is how awful the Linux community can
actually be. That people collect Bitcoins to hire a hitman on me, that
people start petitions to make me stop working, and all that other
really hateful, personal stuff is really apalling. I guess I have a
thick skin, because I don't care too much, but jeezus christ, it's
really disgusting sometimes.)

I monitor the feedback posted on the Internet regularly. I browse
reddit and the debian and gentoo mailing list archives sometimes, and
try to distill the useful bits out of all the noise and hate dumped
there. This actually used to be very productive for quite some time,
and much of the polishing that systemd got over the years was a result
of the feedback I read through this way, even if I had to read between
the lines of all the hateful mails. Today, it's much less useful, I
figure partially because the worst usability issues with systemd have
long been fixed, but also because the crowd commenting changed from
folks who were genuinely interested (early adopter folks) to a more
general audience which also includes a lot of haters.

The current increase noised level around systemd adoption I attribute
to three things: the fact that RHEL7 is out now, the fact that due to
the adoption of systemd as default by Debian and Ubuntu the folks who
ignored the discussion so far now are faced with this change, and also
to a big part to certain "columnists" who in the interest of
generating traffic to their sites try to create a hubbub out of very
little.

Anyway, long story short: we knew what we did, and yeah, I read
feedback, even if it is written in a hateful style, and we learn from
it.

> For now I use systemd. I like quite some features. But on the other hand I am 
> vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 
> 1,3 MiB binary in systemd 215 and wonder myself. I see systemd --user 
> processes running and wonder: 

Well, note that systemd used for user services actually saves you
resources, as the systemd binary only needs to be mapped into memory
once and then is shared between all user instances and the system
instance.

> Is it really all just nay-sayers for the sake of nay-saying? 

No, it's not that simple.

> Or do they – at least partly – provide *valuable* and *important*
> feedback.

Well, some is valuable and important, but much certainly isn't. The
200nd complaint that systemd was "monolithic" or so is something I am
genuinely not interested in anymore, for example...

I will continue to scan reddit and the mailing list archives fo

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

On Tue, Sep 23, 2014 at 9:13 PM, Dale R. Worley  wrote:
> OK, I'd like to modify systemd's handling of mounts.  I've been told
> only that the units that are created from /etc/fstab are created and
> handled by the main systemd binary.  What documentation do I look at
> that explains how systemd actually does that, what the relevant source
> is, etc.?  With init scripts, I know it's somewhere in a script in
> /etc/rc.d/init.d; searching for "mount" probably reveals a couple of
> hundred lines of shell script within which the functionality is
> hiding.

Try "systemctl status home.mount" (or some other mount unit generated
from your fstab), then there will be pointers to the relevant
documentation there ("Doc:"). To be dropped directly into the man
pages, just do "systemctl help home.mount".

> Another more generically useful pointer would be something that
> explains what the algorithm that does the sequencing between units
> *really* is.  I've heard breezy descriptions of what the various
> dependency types mean, but I'm certain that there's a bunch of tricky
> details which a lot of thought has been spent on.

I do not understand this question. Could you give an example of what
you are struggling with? I mean, the gist is that the After/Before
orderings are respected and everything else is done in parallel. To
get the precise orderings applied to a unit try "systemctl show
bar.service".

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 23.09.2014 um 21:13 schrieb Dale R. Worley:
> OK, I'd like to modify systemd's handling of mounts.  I've been told
> only that the units that are created from /etc/fstab are created and
> handled by the main systemd binary.  What documentation do I look at
> that explains how systemd actually does that, what the relevant source
> is, etc.?  With init scripts, I know it's somewhere in a script in
> /etc/rc.d/init.d; searching for "mount" probably reveals a couple of
> hundred lines of shell script within which the functionality is
> hiding

to be fair here: just type "systemd.mount" in Google
http://www.freedesktop.org/software/systemd/man/systemd.mount.html



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: Zbigniew Jędrzejewski-Szmek 

> More seriously, the idea of having shell scripts which you're going
> to modify to customize your setup is simply crazy. How robust would
> your changes be? How would you ever handle upgrades? How would more
> than one admin manage a machine without sitting in the same room?

I've been editing init scripts since around 1992, and I'll bet that a
lot of other people have, too.  It's reasonably robust, since you know
where the edits are and what they're for.  You upgrade by bringing
forward the edits into each new release you load.

But there's no way around that.  Suppose I'd like to adjust systemd's
behavior regarding mounting devices (as I do).  Is that going to be
*easier* to do if I have to download the C, modify it, and recompile?
I still have the same problems with upgrading, etc.

In the end, what wins is usually what makes it easiest to accomplish
the tasks people have at hand.  E.g., in many ways, C is an inferior
language to Pascal, but there are enough things that Pascal makes hard
or impossible that C won out.  Similarly with customizations.

> Again, this seems rather ignorant of the status quo. Between the blog
> posts and wiki documentation and the 164 man pages, systemd is rather
> copiously documented. Not to say that things can't be improved, but
> by Linux standards we are at least making an effort. Bugs for missing
> or unclear documentation and usually handled, and any patches for
> documentation are applied fairly quickly.

OK, I'd like to modify systemd's handling of mounts.  I've been told
only that the units that are created from /etc/fstab are created and
handled by the main systemd binary.  What documentation do I look at
that explains how systemd actually does that, what the relevant source
is, etc.?  With init scripts, I know it's somewhere in a script in
/etc/rc.d/init.d; searching for "mount" probably reveals a couple of
hundred lines of shell script within which the functionality is
hiding.

Another more generically useful pointer would be something that
explains what the algorithm that does the sequencing between units
*really* is.  I've heard breezy descriptions of what the various
dependency types mean, but I'm certain that there's a bunch of tricky
details which a lot of thought has been spent on.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 22, 2014 at 10:16:36AM -0400, Dale R. Worley wrote:
> > From: "Jóhann B. Guðmundsson"
> 
> > > Did you ever ask yourself why your project provokes that amount of
> > > resistance and polarity? Did you ever ask yourself whether this
> > > really is just resistance against anything new from people who
> > > just do not like "new" or whether it contains*valuable*
> > > and*important* feedback?
> > 
> > I'm not sure why you are under the assumption that we do not consider 
> > and have not and are not gathering feedback from individuals, 
> > communities or companies for that matter but I'm going to address your 
> > questions anyway.
> 
> I've brought a complaint about one of systemd's behaviors here.  I
> have gotten useful feedback allowing me to refine what I think would
> be a good solution to the problem.  What I *haven't* gotten is any
> useful feedback on how to implement a solution.  I suspect others have
> had similar experiences.
>
> One metric that might be useful is to ask:  Of the people who complain
> about one or another aspect of systemd, what fraction ultimately
> consider their complaint to be satisfactorily resolved?
Hm, if you looked at any of the bugtrackers, most systemd issues are
resolved (e.g. on bugs.freedesktop.org we have about 140 of of 950
issues still opened). Most of the time they are actually fixed, and
the ones that are left open are either RFEs or more complicated issues.

> There are also "architectural" issues about systemd that I've
> noticed.  I don't know to what degree these indicate quality control
> problems with the code, or whether they are just a matter of things
> being done in ways that are not common in the Un*x universe.  But they
> do seem to me to be things that are going to inhibit adoption.
> 
> 1. Systemd has some very large binaries, each of which implements many
> aspects of the system.  Conversely, the typical Un*x approach is to
> separate functions into many executablels, many of which are scripts.
> The latter approach makes customization easier, especially for
> sysadmins who aren't deeply familiar with the system.
Actually, based on what I've read e.g. in the UNIX haters' handbook,
the idea of separating into many separate binaries wasn't all that
common in UNIX. Also, historically programs used to be real binaries,
not scripts.

More seriously, the idea of having shell scripts which you're going
to modify to customize your setup is simply crazy. How robust would
your changes be? How would you ever handle upgrades? How would more
than one admin manage a machine without sitting in the same room?

I don't know where you get the idea that systemd has "big binaries".
Existing source code compiles to ~140 binaries and a few libraries.
Many of them are really tiny, a few that do more complicated things
are bigger. And things are very much separated by function between
daemons.

> 2. Systemd includes a tremendous number of features and behaviors, but
> a lot of them aren't documented very well.  That's not so unusual in
> Un*x, but if you're introducing something new, nobody has any prior
> knowledge of it, and the lack of documentation becomes visible.
Again, this seems rather ignorant of the status quo. Between the blog
posts and wiki documentation and the 164 man pages, systemd is rather
copiously documented. Not to say that things can't be improved, but
by Linux standards we are at least making an effort. Bugs for missing
or unclear documentation and usually handled, and any patches for
documentation are applied fairly quickly.

> Ultimately, writing e-mail messages saying "They're wrong" is useless,
> even if they *are* wrong.  If there is a substantial body of people
> out there who dislike systemd, it's going to prevent its adoption.
> The fix is adjusting systemd (or the project surrounding it) so that
> people like it better.
Sometimes, sometimes not. Doing everything that is requested, especially
by newcomers to the project, would quickly cause the project to
lose focus and consistency and turn into an unmaintainable mess.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

Let me offer this as a suggestion of what might be the root of some
issues:

One of the lessons in Fred Brooks' "The Mythical Man-Month" is that it
takes three times more effort to produce a *program product* as it
does to produce the *program*.  That is, 2/3 of the effort is not to
make the software do what it is supposed to, but rather to adjust the
software to work in the (software and human) environment that it must
work in, interacting with customers, etc.

It might be worth examining the project and asking whether the
non-software part of the work has been carried out with the same care
as the software part of the work.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Ian Malone]

On 22 September 2014 15:16, Dale R. Worley  wrote:

> 2. Systemd includes a tremendous number of features and behaviors, but
> a lot of them aren't documented very well.  That's not so unusual in
> Un*x, but if you're introducing something new, nobody has any prior
> knowledge of it, and the lack of documentation becomes visible.
>

It's maybe not so unusual in *nix, globbed to include Linux and
starting in the past decade, but is unusual in Unix. When I started on
Linux it was still possible to use all that documentation
(http://www.opengroup.org/ was massively useful) and I spent quite
some time understanding Posix standards and how things fitted
together. You could teach yourself how to programme, use cron,
administer the system, from man pages.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

On Mon, Sep 22, 2014 at 2:44 PM, "Jóhann B. Guðmundsson"
 wrote:
>
> On 09/22/2014 12:07 PM, Reindl Harald wrote:
>
> Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson:
>
>> On 09/22/2014 11:40 AM, Reindl Harald wrote:
>
>>> Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:
>
 On 09/22/2014 09:23 AM, Reindl Harald wrote:
>
> Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:
>
>> The reason for increased log entries in the journal is that more
>> things
>> are happening now since this is what happening when a job is run.
>
> that don't change the fact that a user not acting as
> systemd-developer and not debugging his system don't
> need that flood
>
 I guess we have different meaning of message flood
>
>>> again: we talk about rsyslog, like it or not
>
>>
>> Then file a bug report against rsyslog and provide a patch which fixes
>> the default log filtering in Fedora to your expectation but leave
>> systemd out of it.
>
> wow - in any other case the systemd developers saying that
> they don't workround things because problems has to be
> solved at the root-cause - practice what you preach and
> make the log-verbosility configureable!
>
>
> Serves no purpose whatsoever doing that.
>
>
> * rsyslog is *not* responsible for the message flood produced by systemd
>
>
> No but it is responsible for the filtering <-- of log messages.
>
> * systemd is the one producing it without prefixes
>
>
> This is simply untrue as "journalctl -o export" will show you.
>
> I suggest you stop blaming systemd for your own administrative incompetence
> and broken implementation of rsyslog and syslog-ng in Fedora

Please let's not stoop to this level of name-calling. I haven't
followed this debate in detail, so I don't know how this should be
solved, but it seems fair to say that Harald's experience is
suboptimal, so let's focus on making constructive suggestions for how
journald/rsyslog or the local/distro config could be improved, rather
than who is to blame.

Anyway, I think this is decidedly off-topic for this thread, so please
move this elsewhere.

Cheers,

Tom

> ( I tried to
> get it fixed before we defaulted to journal YES IT WAS BROKEN BEFORE AND
> STILL IS but was not allowed to do so thank those Red Hatters in the
> governing body's of Fedora ( FESCO/FPC ) for it's brokeness  ) and write an
> rsyslog template suited for your environment which will filter things to
> your liking and expectation or better yet complain to those FESCO/FPC
> members since they need to learn a hard lesson of accepting responsibility
> for their own actions in the distribution.
>
> You can find how to write an rsyslog template in the upstream rsyslog
> documentation using it's powerful filtering capabilities and by looking at
> for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf in
> Fedora.
>
> JBG
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 16:41 schrieb Simon McVittie:
> On 22/09/14 10:23, Reindl Harald wrote:
>> honestly the messages about "reaching target" are nonsense without 
>> a prefix pointing out that it is about a *user session* because it 
>> looks like a bootlog every minute
> 
> You can tell this is not the system instance of systemd (init) because
> its process ID is > 1. systemd[1] indicates the system instance,
> systemd[anything else] is a user instance. This might be a useful
> basis for a filter.

first: thank you for a normal answer instead "shut up and go away"

if you take that as decision for drop messages you have several problems

* drop anything from "systemd" with PID != 1 will also affect
  future things nobody knows now and not related to user-sessions
  and so not happening every minute caused by cron
* it is wasting of ressources for produce *and* filter the messages

> Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf
> would probably also help in your situation

why is it refused with such a vehemence to consider make
default loggings not that verbose in general and act like
many other software packages: configured log levels with
non verbose defaults

* informational
* warning
* error
* fatal error

the goal should not be produce a growing amount over the time
and then force users how to filter it away - it should not
be produced (produce and filter both taking ressources)

the relevant information "New session started" was already
produced by systemd-logind before introduce the new verbose
log and that was easy to direct to /var/log/secure because
the process name

the normal user cares about

* started
* no error logged
* ended

but not about more details until something needs debugging
which is unusual as long you are not a systemd-developer






signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Simon McVittie]

On 22/09/14 10:23, Reindl Harald wrote:
> honestly the messages about "reaching target" are nonsense without 
> a prefix pointing out that it is about a *user session* because it 
> looks like a bootlog every minute

You can tell this is not the system instance of systemd (init) because
its process ID is > 1. systemd[1] indicates the system instance,
systemd[anything else] is a user instance. This might be a useful
basis for a filter.

Configuring a higher (more severe) LogLevel in /etc/systemd/user.conf
would probably also help in your situation.

S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Dale R. Worley]

> From: "Jóhann B. Guðmundsson"

> > Did you ever ask yourself why your project provokes that amount of
> > resistance and polarity? Did you ever ask yourself whether this
> > really is just resistance against anything new from people who
> > just do not like "new" or whether it contains*valuable*
> > and*important* feedback?
> 
> I'm not sure why you are under the assumption that we do not consider 
> and have not and are not gathering feedback from individuals, 
> communities or companies for that matter but I'm going to address your 
> questions anyway.

I've brought a complaint about one of systemd's behaviors here.  I
have gotten useful feedback allowing me to refine what I think would
be a good solution to the problem.  What I *haven't* gotten is any
useful feedback on how to implement a solution.  I suspect others have
had similar experiences.

One metric that might be useful is to ask:  Of the people who complain
about one or another aspect of systemd, what fraction ultimately
consider their complaint to be satisfactorily resolved?

There are also "architectural" issues about systemd that I've
noticed.  I don't know to what degree these indicate quality control
problems with the code, or whether they are just a matter of things
being done in ways that are not common in the Un*x universe.  But they
do seem to me to be things that are going to inhibit adoption.

1. Systemd has some very large binaries, each of which implements many
aspects of the system.  Conversely, the typical Un*x approach is to
separate functions into many executablels, many of which are scripts.
The latter approach makes customization easier, especially for
sysadmins who aren't deeply familiar with the system.

2. Systemd includes a tremendous number of features and behaviors, but
a lot of them aren't documented very well.  That's not so unusual in
Un*x, but if you're introducing something new, nobody has any prior
knowledge of it, and the lack of documentation becomes visible.

Ultimately, writing e-mail messages saying "They're wrong" is useless,
even if they *are* wrong.  If there is a substantial body of people
out there who dislike systemd, it's going to prevent its adoption.
The fix is adjusting systemd (or the project surrounding it) so that
people like it better.

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 15:55 schrieb Jóhann B. Guðmundsson:
> On 09/22/2014 12:58 PM, Reindl Harald wrote:
>> i suggest you get rid of that arrogance and some other developers
>> too because it's the reason for the subject and proves that you
>> *do not* care about users as long you have not the same opinion
>>
>> you are the one demanding a friendly tone from me, well, than
>> practice what you preach or stop whining if someone calls you
>> names the next time
>>
>> who do you think you are to assess others incompetence?
> 
> I think I'm the one based on your own actions as in after you cant even take 
> your time to a read upstream rsyslog
> documentation then insert a single line of filtering in rsyslog, similar or 
> equivalent of
> 
> ":programname, isequal, "systemd"
> -/var/log/systemd.log"

no you refuse to understand that *nobody* wants to split
out *all* systemd logs because just the excessive *user
session* logging and that this messages should not exist
at all in a non-debugging environment

you also refuse to understand that the intention in
production environments using a *centralized* SQL
logging is do *drop that messages* but hardly to
drop anything from systemd

so the next time before you take "incompetence"
in your mouth try to understand the context or
ask yourself on which side it exists

> clutter the comment sections with useless output in those bug
> reports "to prove your point over and over again" and call the 
> lead developer of the project an idiot

cause and effect - what reaction did he expect by
follow a link to a for weeks existing bugreport and
as only action close it with "NOBUG" a minute later

> in one of those reports  then show up upstream cursing and demanding fixes
> saying that systemd message cant be filtering even thou I pointed  to 
> "journalctl
> -o export" which shows all the messages fields each log contains including 
> all the
> syslog entries which should provide an capable administrator pleathora of 
> ideas 
> how to filter message in conjunction with rsyslog powerful filtering 
> capabilities 
> and all that rant for something that is not our to fix in the firstplace.

surely - you have no need to produce that flood in the first instance
and if you as systemd-developer want that informations then enable
deugging but stop to decide what every user needs to have in his logs
or actively to filter

realize that the world don't turn around systemd developers and
just stop your arrogance and ignorance - you will wonder how
friendly the same people become complaining all the time if
upstream stops to handle users like someone who disturbs

> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/22/2014 12:58 PM, Reindl Harald wrote:

i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not*  care about users as long you have not the same opinion

you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time

who do you think you are to assess others incompetence?


I think I'm the one based on your own actions as in after you cant even 
take your time to a read upstream rsyslog documentation then insert a 
single line of filtering in rsyslog, similar or equivalent of


":programname, isequal, "systemd" -/var/log/systemd.log"

to filter out systemd message from /var/log/message or fine tune the 
filtering through the use of rsyslog templates and submit that as a 
patch against rsyslog in Fedora so the distribution can improve it's 
default filtering in rsyslog based on your input but instead choose to 
file gazillion bug reports against systemd which has nothing to do with 
the text file filtering in the distribution,  clutter the comment 
sections with useless output in those bug reports "to prove your point 
over and over again" and call the lead developer of the project an idiot 
in one of those reports then show up upstream cursing and demanding 
fixes saying that systemd message cant be filtering even thou I pointed 
to "journalctl -o export" which shows all the messages fields each log 
contains including all the syslog entries which should provide an 
capable administrator pleathora of ideas how to filter message in 
conjunction with rsyslog powerful filtering capabilities and all that 
rant for something that is not our to fix in the firstplace.


1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Philippe De Swert]

Hi,

On 22/09/14 15:58, Reindl Harald wrote:
> 
> Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
> Then file a bug report against rsyslog and provide a patch which fixes 
> the default log filtering in Fedora to your expectation but leave 
> systemd out of it.
>>> wow - in any other case the systemd developers saying that
>>> they don't workround things because problems has to be
>>> solved at the root-cause - practice what you preach and
>>> make the log-verbosility configureable!
>>
>> Serves no purpose whatsoever doing that.

Could you elaborate? As generating 8 lines of log seems a bit
excessive (seems in one bug which is linked it is rather a
calculationg). I would definitly classify that as a bug. (It could for
example keep a cpu or system from sleeping, thus draining more power).

Anyway usually less debug is better as it is more obvious where a
problem might be imho. Of course it is always a question about finding a
balance.

>>> * rsyslog is *not* responsible for the message flood produced by systemd
>>
>> No but it is responsible for the filtering <-- of log messages.
>>>
>>> * systemd is the one producing it without prefixes
>
> it is ridiculous to have the need of filtering
> 
>> This is simply untrue as "journalctl -o export" will show you.
> 
> where is it in the message?
> the process is "systemd"

Instead of blaming someone for being incompetent you could just have
given the solution. Especially as you mentioned you knew something like
that might happen but blamed Red Hat for not implementing a potential
fix. Which you could have even documented and somebody could have found
googling for it. That would have saved time for everybody involved.

Although from what I know I rather agree there is a bug in systemd.

You also seem to forget systemd adds a lot of layers of complexity that
just did not exist with the old init. It makes it a lot harder to find
out what is going on (despite all the available documentation). So if
the prefix does not show in an obvious manner I could categorize that as
a bug too. In this case it might actually make sense to have a different
prefix as it will clearly indicate user vs system session.

Also despite the loglevels available in journald. It is unclear from the
documentation how the classification gets done
http://www.freedesktop.org/software/systemd/man/journald.conf.html

Maybe for our problem MaxLevelSyslog=err might work? But how do we know
it won't suppress certain messages we would like to see and actually
suppresses the one we don't want?

Regards,

Philippe


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
>>> > Then file a bug report against rsyslog and provide a patch which fixes 
>>> > the default log filtering in Fedora to your expectation but leave 
>>> > systemd out of it.
>> wow - in any other case the systemd developers saying that
>> they don't workround things because problems has to be
>> solved at the root-cause - practice what you preach and
>> make the log-verbosility configureable!
> 
> Serves no purpose whatsoever doing that.
>>
>> * rsyslog is *not* responsible for the message flood produced by systemd
> 
> No but it is responsible for the filtering <-- of log messages.
> 
>> * systemd is the one producing it without prefixes

it is ridiculous to have the need of filtering

> This is simply untrue as "journalctl -o export" will show you.

where is it in the message?
the process is "systemd"

how to distinct between user sessions and systemn boot?
":programname" don't work and ":msg, startswith" don't work

Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths.
...

> I suggest you stop blaming systemd for your own administrative incompetence 

i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion

you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time

who do you think you are to assess others incompetence?

> and broken implementation of rsyslog and syslog-ng in Fedora 
> (I tried to get it fixed before we defaulted to journal YES IT 
> WAS BROKEN BEFORE AND STILL IS but was not allowed to do so 
> thank those Red Hatters in the governing body's of Fedora 
> ( FESCO/FPC ) for it's brokeness) 

just don't create messages the majority of users don't want and need
to see until debugging and even systemd needs to realize that the
world is not turning around it

> and write an rsyslog template suited for your environment which 
> will filter things to your liking and expectation or better yet
> complain to those FESCO/FPC members since they need to learn a 
> hard lesson of accepting responsibility for their own actions 
> in the distribution

who do you think you are?

that arrogance and pure ignorance is the reason for subject and
related websites as well as for users from time to time not
complaining as nice as you would like it

hence fedora devel CC'ed
__

here the relevant links you decided to strip out and replace
with your arrogant abuse as you always do if someone has a
differnt opinion but demand from others not act the same way

here you have a simple calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8

why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
and the workaround "loginctl enable-linger" leads to another bugreport
open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/22/2014 12:07 PM, Reindl Harald wrote:

Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson:

>On 09/22/2014 11:40 AM, Reindl Harald wrote:

>>Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:

>>>On 09/22/2014 09:23 AM, Reindl Harald wrote:

Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:

>The reason for increased log entries in the journal is that more things
>are happening now since this is what happening when a job is run.

that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood

>>>I guess we have different meaning of message flood

>>again: we talk about rsyslog, like it or not

>
>Then file a bug report against rsyslog and provide a patch which fixes
>the default log filtering in Fedora to your expectation but leave
>systemd out of it.

wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!


Serves no purpose whatsoever doing that.



* rsyslog is*not*  responsible for the message flood produced by systemd


No but it is responsible for the filtering <-- of log messages.


* systemd is the one producing it without prefixes


This is simply untrue as "journalctl -o export" will show you.

I suggest you stop blaming systemd for your own administrative 
incompetence and broken implementation of rsyslog and syslog-ng in 
Fedora ( I tried to get it fixed before we defaulted to journal YES IT 
WAS BROKEN BEFORE AND STILL IS but was not allowed to do so thank those 
Red Hatters in the governing body's of Fedora ( FESCO/FPC ) for it's 
brokeness  ) and write an rsyslog template suited for your environment 
which will filter things to your liking and expectation or better yet 
complain to those FESCO/FPC members since they need to learn a hard 
lesson of accepting responsibility for their own actions in the 
distribution.


You can find how to write an rsyslog template in the upstream rsyslog 
documentation using it's powerful filtering capabilities and by looking 
at for example the one spice-vdagentd /etc/rsyslog.d/spice-vdagentd.conf 
in Fedora.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson:
> On 09/22/2014 11:40 AM, Reindl Harald wrote:
>> Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:
>>> On 09/22/2014 09:23 AM, Reindl Harald wrote:
 Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:
> The reason for increased log entries in the journal is that more things
> are happening now since this is what happening when a job is run.
 that don't change the fact that a user not acting as
 systemd-developer and not debugging his system don't
 need that flood
>>> I guess we have different meaning of message flood
>> again: we talk about rsyslog, like it or not
> 
> Then file a bug report against rsyslog and provide a patch which fixes 
> the default log filtering in Fedora to your expectation but leave 
> systemd out of it.

wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!

* rsyslog is *not* responsible for the message flood produced by systemd
* systemd is the one producing it without prefixes

produce 8 loglines noise on a small infrastructure is insane
that's the same all other services produce together

is it really that hard to accept that this level of informations
is only helpful for debugging, produces overhead if it could
be filtered away and anyways has the bad impact that journald
in rsyslog envoironments has the whole day to do with rotate

[Journal]
Storage=volatile
Compress=yes
RateLimitInterval=10s

frankly i have seen more or less idle machines where journald is
one of the top ressource consumers

>> what you filter below is what i have in /var/log/cron and /var/log/secure
>> but the other messages spit to the log are a lot more
>>
>> here you have a simple calculation
>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8
>>
>> why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>> and the workaround "loginctl enable-linger" leads to another bugreport
>> open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
>>
>> so what we have now is log flooding or hanging shutdowns
>> why don't upstream just what users would help and reduce logging
>> in a non-debug mode to a minimum so one can see without filter
>> if something unusal happens on a system?
>>
>> if the developers would accept the need of their users then likely the users
>> would also be more positive, just don't explain me how to maintain my servers
>>
>> i am fine with distribute-command.sh "cat /var/log/messages" all they
>> years because the general log is silent until something bad happens
>>
>> you can't do that if systemd floods it for 30 machines
>>
>>> # journalctl -f
>>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of 
>>> user johannbg.
>>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of 
>>> user johannbg.
>>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD 
>>> (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
>>> journal cron job log test every minute" )
>>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job 
>>> log test every minute
>>>
>>> Hey let's filter this even further
>>>
>>> # journalctl -f SYSLOG_IDENTIFIER=CROND
>>> -- Logs begin at Thu 2013-10-24 11:47:22 GMT. --
>>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD 
>>> (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
>>> journal cron job log test every minute" )
>>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job 
>>> log test every minute
>>>
>>> Anything regarding an text file and local and or remote logging using 
>>> either rsyslog or syslog-ng is and it's
>>> default is not relevant to us and usually set by distribution maintainers.
>>>
>>> For remote logging I would assume administrator would create an cron filter 
>>> which has the syslog identifier crond
>>> or CROND, the syslog facility 9 and an priority 6 and send that to the 
>>> remote server
>>>
>>> So if systemd output is too much in any text file <-- file a bug against 
>>> rsyslog or syslog-ng depending on which
>>> the distribution and have *them* fix their default filtering



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/22/2014 11:40 AM, Reindl Harald wrote:

Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:

On 09/22/2014 09:23 AM, Reindl Harald wrote:

Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:

The reason for increased log entries in the journal is that more things
are happening now since this is what happening when a job is run.

that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood

I guess we have different meaning of message flood

again: we talk about rsyslog, like it or not


Then file a bug report against rsyslog and provide a patch which fixes 
the default log filtering in Fedora to your expectation but leave 
systemd out of it.




what you filter below is what i have in /var/log/cron and /var/log/secure
but the other messages spit to the log are a lot more

here you have a simple calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8

why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
and the workaround "loginctl enable-linger" leads to another bugreport
open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54

so what we have now is log flooding or hanging shutdowns
why don't upstream just what users would help and reduce logging
in a non-debug mode to a minimum so one can see without filter
if something unusal happens on a system?

if the developers would accept the need of their users then likely the users
would also be more positive, just don't explain me how to maintain my servers

i am fine with distribute-command.sh "cat /var/log/messages" all they
years because the general log is silent until something bad happens

you can't do that if systemd floods it for 30 machines


# journalctl -f
Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user 
johannbg.
Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user 
johannbg.
Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t 
"CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log 
test every minute

Hey let's filter this even further

# journalctl -f SYSLOG_IDENTIFIER=CROND
-- Logs begin at Thu 2013-10-24 11:47:22 GMT. --
Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t 
"CROND" /bin/echo "Systemd
journal cron job log test every minute" )
Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log 
test every minute

Anything regarding an text file and local and or remote logging using either 
rsyslog or syslog-ng is and it's
default is not relevant to us and usually set by distribution maintainers.

For remote logging I would assume administrator would create an cron filter 
which has the syslog identifier crond
or CROND, the syslog facility 9 and an priority 6 and send that to the remote 
server

So if systemd output is too much in any text file <-- file a bug against 
rsyslog or syslog-ng depending on which
the distribution and have *them* fix their default filtering

JBG


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:
> The reason for increased log entries in the journal is that more things
> are happening now since this is what happening when a job is run.

that don't change the fact that a user not acting as
systemd-developer and not debugging his system don't
need that flood

you need to distinct between users and developers
users want to have *abnormal* things logged and
not burried inside noise

> Those that have cron job that send email that notifies every time that it ran 
> ( to know it ran ) and those that do
> not send an email unless the job it was running failed and rely on logwatch 
> to inform them if the cron job ran or not.
>>
>>> If you dont like it filter it and retrieve only the information you 
>>> want/need with journalctl
>> if they would have a prefix i would filter them to nowhere in rsyslog
>>
>> please understand that not everybody is using journalctl
> 
> Well this is upstream that ships nothing but journalctl whether they use it 
> or not

then add at least *prefixes* to write filter rules
what you say is "we don't ship nothing but" and "we don't care about nothing 
but"

that is the reason for the polarity "we are upstream and don't care"
just give "journald.conf" a verbosity option and all are happy

honestly the messages about "reaching target" are nonsense without
a prefix pointing out that it is about a *user session* because it
looks like a bootlog every minute

Mar  4 13:01:01 rawhide systemd[1559]: Starting Paths.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Paths.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Timers.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Timers.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Sockets.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Sockets.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Basic System.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Basic System.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Default.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Default.
Mar  4 13:01:01 rawhide systemd[1559]: Startup finished in 9ms.



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Uoti Urpala]

On Sun, 2014-09-21 at 15:31 +0200, Martin Steigerwald wrote:
> Did you ever ask yourself why your project provokes that amount of resistance 
> and polarity? Did you ever ask yourself whether this really is just 
> resistance 
> against anything new from people who just do not like "new" or whether it 
> contains *valuable* and *important* feedback?

I think that in general the existence of significant amounts of
resistance is explained by opposition to anything new. Systemd changes
many things, and as distros won't keep support for sysvinit at the same
time, people can't easily keep using the old stuff they're used to.
That's enough to explain complaints, and their existence does not by
itself mean there would be anything wrong with systemd.


> For now I use systemd. I like quite some features. But on the other hand I am 
> vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 
> 1,3 MiB binary in systemd 215 and wonder myself.

Sysvinit as PID 1 lacks many essential things, so that is not a valid
size comparison (and just having the code running with a PID other than
1 is not an improvement).

In general, any complaints about the size/"bloat" of PID 1 are rather
silly if you still use it with the Linux kernel, which contains a lot
more code in a more central role than PID 1.


>  I had it that it didn´t mount an NFS export and while in the 
> end it was a syntax error in fstab that sysvinit happily ignored, I needed a 
> bug report and dev help to even find that cause. I wonder about the 
> complexity 
> involved in one single large binary.

I think this works as an example of how change leads to people
complaining, completely unrelated to the existence of any actual quality
issues. Sysvinit behavior or debuggability wrt mount issues was not
better than systemd is, much less by so much that this would illustrate
any general issue with systemd (that's not to say that systemd
diagnostics could not be improved). Yet because you were first familiar
with sysvinit and had created dubious configuration which happened to
work with it, you now feel this is a problem in systemd, just because
things have changed. Someone who started with systemd and used it for
years before encountering sysvinit would hit a lot more problems.


> Well… its not about my thoughts about systemd, it is about my perception that 
> I never seen any free software upstream project creating this amount of 
> polarity and discussion in a decade or more.

I don't think the reactions to systemd are in any way unique. I've seen
similar reactions to other changes. The difference in the systemd case
is that a lot of developers interact with the init system at least on a
superficial level, and init system choice is mostly done on the distro
level, so people can't easily ignore systemd and keep using their old
software. That increases the volume of the complaints.


> Is it really all just nay-sayers for the sake of nay-saying? Or do they – at 
> least partly – provide *valuable* and *important* feedback.

"nay-sayers" as in people who oppose the adoption of systemd because
they think that some alternative is less flawed tend to have no clue.
You're more likely to get *valid* criticism from people who are at least
competent enough to recognize that whatever problems systemd has, the
alternatives are worse.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/21/2014 11:09 PM, Reindl Harald wrote:

Am 22.09.2014 um 00:48 schrieb Jóhann B. Guðmundsson:

On 09/21/2014 10:23 PM, Reindl Harald wrote:

Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:

Now alot of the resistance and polarity that is taking place like in the url 
you pointed at is hiding itself

behind

their misinterpretation of the so called "Unix philosophy" and claiming that we 
somehow fall short on the
guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said 
sometime in the 70's or rather the
"Unix philosophy" was implied not by what these individuals said but rather by 
what they did which more or less
boils down to this..
11. When a program has nothing surprising to say, it should say nothing

then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315

?

I dont see the connection here systemd is informing you what start/stopped when 
these cron job ran

with *that many* lines?


The reason for increased log entries in the journal is that more things 
are happening now since this is what happening when a job is run.




that information already exists in /var/log/secure and /var/log/cron
these lines are completly useless for a non-developer


Irrelevant to us what is stored in text files so that needs to be 
handled downstream.




consider that not refuse that often what a user wants to
see or not to see *as default* because as developer you
have other needs is one of the reasons *endusers* get
sometimes really angry


Depends on personal preference and practices

Cron users already are divided into two religious notification groups.

Those that have cron job that send email that notifies every time that 
it ran ( to know it ran ) and those that do not send an email unless the 
job it was running failed and rely on logwatch to inform them if the 
cron job ran or not.





If you dont like it filter it and retrieve only the information you want/need 
with journalctl

if they would have a prefix i would filter them to nowhere in rsyslog

please understand that not everybody is using journalctl


Well this is upstream that ships nothing but journalctl whether they use 
it or not.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 00:48 schrieb Jóhann B. Guðmundsson:
> On 09/21/2014 10:23 PM, Reindl Harald wrote:
>> Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:
>>> >Now alot of the resistance and polarity that is taking place like in the 
>>> >url you pointed at is hiding itself
>>> behind
>>> >their misinterpretation of the so called "Unix philosophy" and claiming 
>>> >that we somehow fall short on the
>>> >guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson 
>>> >said sometime in the 70's or rather the
>>> >"Unix philosophy" was implied not by what these individuals said but 
>>> >rather by what they did which more or less
>>> >boils down to this..
>>> >11. When a program has nothing surprising to say, it should say nothing
>> then flood logs with nothing relevant should not happen
>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>> https://bugzilla.redhat.com/show_bug.cgi?id=1053315
> 
> ?
> 
> I dont see the connection here systemd is informing you what start/stopped 
> when these cron job ran

with *that many* lines?

that information already exists in /var/log/secure and /var/log/cron
these lines are completly useless for a non-developer

consider that not refuse that often what a user wants to
see or not to see *as default* because as developer you
have other needs is one of the reasons *endusers* get
sometimes really angry

> If you dont like it filter it and retrieve only the information you want/need 
> with journalctl

if they would have a prefix i would filter them to nowhere in rsyslog

please understand that not everybody is using journalctl and if it
is only because using centralized logs in databases since long
before systemd was introduced



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/21/2014 10:23 PM, Reindl Harald wrote:

Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:

>Now alot of the resistance and polarity that is taking place like in the url 
you pointed at is hiding itself behind
>their misinterpretation of the so called "Unix philosophy" and claiming that 
we somehow fall short on the
>guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said 
sometime in the 70's or rather the
>"Unix philosophy" was implied not by what these individuals said but rather by 
what they did which more or less
>boils down to this..
>11. When a program has nothing surprising to say, it should say nothing

then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315


?

I dont see the connection here systemd is informing you what 
start/stopped when these cron job ran.


If you dont like it filter it and retrieve only the information you 
want/need with journalctl.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 00:15 schrieb Jóhann B. Guðmundsson:
> Now alot of the resistance and polarity that is taking place like in the url 
> you pointed at is hiding itself behind
> their misinterpretation of the so called "Unix philosophy" and claiming that 
> we somehow fall short on the
> guidelines originates from few things Doug McIlroy,Rob Pike,Ken Thompson said 
> sometime in the 70's or rather the
> "Unix philosophy" was implied not by what these individuals said but rather 
> by what they did which more or less
> boils down to this..

> 11. When a program has nothing surprising to say, it should say nothing

then flood logs with nothing relevant should not happen
https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1053315

appeared the first time: 2014-01-14
reported: 2014-03-04
refused to fix: 2014-03-24



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Jóhann B. Guðmundsson]

On 09/21/2014 01:31 PM, Martin Steigerwald wrote:

in the light of the ongoing discussions on linux-kernel


Could you provide a link to that ongoing discussion that is taking place 
in the kernel community regarding systemd?



Did you ever ask yourself why your project provokes that amount of resistance
and polarity? Did you ever ask yourself whether this really is just resistance
against anything new from people who just do not like "new" or whether it
contains*valuable*  and*important*  feedback?


I'm not sure why you are under the assumption that we do not consider 
and have not and are not gathering feedback from individuals, 
communities or companies for that matter but I'm going to address your 
questions anyway.


Have we ever asked ourselves why our project provokes that amount of 
resistance and polarity?


The answer to that question is yes, yes we have and yes we will continue 
to do so since resistance and polarity provides with the valuable 
information amongst other things if the implementation is bad and 
alternative approach is better ( which often reveals itself at the same 
time those friction take place ).


Dont get me wrong we will not do so when those discussion involve 
nothing but personal attack on our community member(s) which more often 
than not happens to be Lennart, Lennart is and never has been the sole 
person behind this effort, he's part of ever growing community.


Nor when it involves us having to implement somekind of hack as opposed 
to have the problem properly fixed where it belongs ( which could be us 
or not ) or when those discussion criticizes that we have chosen to 
tightly integrate ourselves specifically to the linux kernel it's 
ecosystem and with glibc in mind just like bsd based distribution as 
well as solaris and other nixes are tightly integrating their components 
to their kernels but for some dumbfound reason people on the internet 
are under the assumption that they have the authority of refusing us the 
freedom of doing the same o_O and the answer to those individuals we 
dont care about their opinion on this matter.


Now alot of the resistance and polarity that is taking place like in the 
url you pointed at is hiding itself behind their misinterpretation of 
the so called "Unix philosophy" and claiming that we somehow fall short 
on the guidelines originates from few things Doug McIlroy,Rob Pike,Ken 
Thompson said sometime in the 70's or rather the "Unix philosophy" was 
implied not by what these individuals said but rather by what they did 
which more or less boils down to this..


1. Write simple parts connected by clean interfaces.
2. Clarity is better than cleverness.
3. Design programs to be connected to other programs.
4. Separate policy from mechanism; separate interfaces from engines.
5. Design for simplicity; add complexity only where you must.
6. Write a big program only when it is clear by demonstration that 
nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and 
debugging easier.

8. Robustness is the child of transparency and simplicity.
9. Fold knowledge into data so program logic can be stupid and robust.
10. In interface design, always do the least surprising thing.
11. When a program has nothing surprising to say, it should say nothing.
12. When you must fail, fail noisily and as soon as possible.
13. Programmer time is expensive; conserve it in preference to machine time.
14. Avoid hand-hacking; write programs to write programs when you can.
15. Prototype before polishing. Get it working before you optimize it.
16. Distrust all claims for “one true way”.
17. Design for the future, because it will be here sooner than you think.

Now after you have read these more of an guidelines than actual 
philosophy I would like to hear from you where you think systemd has and 
is falling short of them during it's development phase and lifetime so I 
can better understand why people seem to be claiming it's not following 
these guidelines?


That being said acceptance and approval are outweighing resistance and 
polarity in the Linux ecosystem as things currently stand ( otherwise we 
would not be so widely accepted and adopted ) because we are and 
continue to solve real problems through close collaboration with wide 
variety of upstream and distribution, In the long run freeing up 
contributors time while doings so through the consolidation that takes 
place while we are at it.


If you are wondering as well if we are against emerging alternative init 
system like the one you refereed to, the answer to that question is no 
we are not.


We welcome and embrace them and hope they evolve to the point they 
become competing solution so we can continue to evolve ourselves ( or 
advance beyond us and eventually replace us ) but being frank that wont 
happen anytime soon.


Systemd has been what ca 7 years in the making now with what 5 of those 
years being direct integration with wide variety of component

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Michael Biebl]

2014-09-21 23:52 GMT+02:00 Tom Gundersen :
> On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald  
> wrote:
>> I had it that it didn´t mount an NFS export and while in the
>> end it was a syntax error in fstab that sysvinit happily ignored, I needed a
>> bug report and dev help to even find that cause. I wonder about the 
>> complexity
>> involved in one single large binary.
>
> PID1 does not parse your fstab, it is done by an external binary. That
> said, if there is a lack of output when a malformed entry is found, we
> should probably improve on that (I don't have the bug report in front
> of me, but please open an RFE if you think this is still not ideal).


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755506#25
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Mantas Mikulėnas]

On Mon, Sep 22, 2014 at 12:52 AM, Tom Gundersen  wrote:
> On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald  
> wrote:
>> http://uselessd.darknedgy.net/
>
> Hm, missing content?

Apparently someone attacked and wiped their website.

It's mostly a trimmed-down systemd fork:
https://bitbucket.org/bcsd/uselessd (or slashdot, phoronix, etc.)

>> Debian Bug report logs - #746715
>> the foreseeable outcome of the TC vote on init systems
>> https://bugs.debian.org/bug=746715
>
> "this package no longer exists" ?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Tom Gundersen]

On Sun, Sep 21, 2014 at 3:31 PM, Martin Steigerwald  wrote:
> I just have one question. In the light of
>
> http://boycottsystemd.org/

Please note that this is just (to the best of my knowledge), the
misinformed rants of an anonymous individual (despite it appearing a
lot more serious due to the guy buying a domain).

> http://uselessd.darknedgy.net/

Hm, missing content?

> Debian Bug report logs - #746715
> the foreseeable outcome of the TC vote on init systems
> https://bugs.debian.org/bug=746715

"this package no longer exists" ?

> Did you ever ask yourself why your project provokes that amount of resistance
> and polarity? Did you ever ask yourself whether this really is just resistance
> against anything new from people who just do not like "new" or whether it
> contains *valuable* and *important* feedback?

We occasinoally got some very critical feedback that is also very
good. However, when you look at the various "debates" in other forums
(such as the ones you mentioned), my impression is that it is almost
entirely useless noise. I.e., either people are complaining about
things that are based entirely on misconceptions, or they are
complaining about things that had a root in something reasonable once
upon a time, but have long since been either explained or fixed.

> I am taking this upstream with you, cause I think too much of this is
> resignately been discussed elsewhere, discussed elsewhere for as I got the
> feedback on various occasions where I recommended to take feedback upstream
> that people have no hope in having their feedback considered at all.

If people bring useful and at least moderately civil feedback upstream
(i.e., technical feedback in terms of bug reports, questions, RFE's or
similar, not rants amounting to "please stop what you are doing and go
away"), we do take it very seriously, and answer them to the best of
our abilities. That does not mean that every patch is accepted, nor
every request is adhered to, but at least you should get an answer
with an explanation.

The only way to find out is to try though.

> For now I use systemd. I like quite some features. But on the other hand I am
> vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a
> 1,3 MiB binary in systemd 215 and wonder myself.

systemd is a lot more powerful than sysvinit, and does take up more
space. We are not really optimizing the size of the binary, so if you
are interested in looking into making it smaller that's certainly
possible.

> I see systemd --user
> processes running and wonder: Why does the user related stuff need to be in 
> the
> systemd binary.

This is rather the other way around: the problem solved by PID1, is
almost entirely the same as the problem that needs to be solved by the
user session manager, so we allow the same code to be reused. The
amount of code specific to user sessions in PID1 is really very small.

> I had it that it didn´t mount an NFS export and while in the
> end it was a syntax error in fstab that sysvinit happily ignored, I needed a
> bug report and dev help to even find that cause. I wonder about the complexity
> involved in one single large binary.

PID1 does not parse your fstab, it is done by an external binary. That
said, if there is a lack of output when a malformed entry is found, we
should probably improve on that (I don't have the bug report in front
of me, but please open an RFE if you think this is still not ideal).
The reason we reject invalid fstab entries, is that we think it is
safer to fail hard if we cannot know for certain what the admin
intended to do. It is regrettable that this means that the transition
is not as smooth as it otherwise would be, but overall we believe it
is the correct thing to do.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel