[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 
> those concerns are still there… either… its due to Debian adopting systemd 
> now, but its not only Debian users and devels here giving that concerns… or it 
> is due to that the once voicing the concerns have the impression that systemd 
> upstream did not address them.

With the utmost respect, I think in many cases the only way upstream
could "address" some of the voiced concerns would be to simply stop
developing. This is obviously not something that can happen.

>From what I can tell (feel free to correct me if I'm wrong) all of the
technical concerns you've raised in this thread have been addressed. You
may disagree with the response, but that doesn't mean the topic has not
been discussed and put to bed. I've not seen too much counter-discussion
actually around these technical points however.

>> 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.

And sometimes the best way to do something is not always easy ;)

> It took KDE developers several years to split out KDE 4 into modules. Yet they 
> did it. And from what I read on their mailinglists so far, usually their 
> discussions are in a much more friendly tone.

I'm sorry, but I have to disagree about KDE4 here. As you may know I
have been a KDE developer (still am technically!) and participated in
packaging of KDE downstream. Splitting things up like this has very
little practical benefit. Downstreams (distros) still update things in
lockstep, so it's actually more work for distros although I do concede
at times it's easier to make a small tweak to something that builds
quickly, but systemd doesn't cross the threshold into taking forever to
build yet.  In addition, some parts are still huge and contain, from an
outsiders perspective, many disparate parts (e.g. kde-runtime).

But overall, I don't think that splitting everything up to the n'th
degree works. I agree there is a balance, but IMO, by it's nature as a
base building block of OSes, systemd would not benefit from this.

Putting together an OS used to be a complex myriad of different scripts
and baroque tools pulled in from all over the place. systemd solved a
lot of that. It's easy to document and work with in it's current form.
Having split up modules that are kept in lockstep would just make that
more complex. An it doesn't address the vast majority of the concerns
I've heard voiced, so would be a pointless exercise as I've previously
stated.

> Now systemd is not KDE, granted… but I think thats not the only example where 
> developers took quite some extra effort in order to split things out.

I don't mean to put words in your mouth, but you seem to suggest that
splitting things out would be the right course of action? If that's the
case, have you looked over the components of systemd and thought about
that split, or are you just talking about this from a purely
philosophical perspective? Do you honestly think that if all the
components were split out in separate git repos, and thus required
distributions to glue things together downstream (still in lockstep),
that this would help?

One argument I've heard that says it would, is that this allows
independent implementations of the various sub-components. Personally, I
really don't buy this argument. Who is going to reimplement those
components? Lone users on their own systems, distributions, or some
commercial entity? To be honest it doesn't matter! If they want to
replace those components they totally can. Just do it, plug them in in
your operating system, make sure you implement the same ABI - including
DBus interfaces (if you don't want to rebuild other components) or API
(if you don't mind rebuilding) and you're fine. The documentation of the
APIs in systemd is very good. It's one of the best documented projects
I've seen. The fact the sub-component is in a separate git repo makes
absolutely zero difference to this end goal; it's just perception pure
and simple. It doesn't make sense for upstream to go out of their way
here to do something that's already easy for any sufficiently motivated
person or entity.

WHehter they are a distribution or a commercial company creating a
product, they can engineer things however they like. They can put the
subcomponents together as they see fit.

Honestly, I cannot think of any practical reason why splitting things
out would be better.

>> So overall, keeping things developed as one project is a technical
>> decision that has real benefits both for the developers doing the work
>> and the downstreams consuming it. Changing the approach would be 100%
>> political and, quite frankly, the systemd developers have very little
>> time for such games. They just want to get on and build better systems.
> 
> It would be 100% political if the concerns where 100% political. But in my 
> oppinion they are not.

I think we just have to agree to disagree here. I've not yet seen any
compelling technical arguments as to why this would be a good idea.

>>> What of this actually *needs* to be coupled with systemd? What of this
>>> needs to be coupled tightly to Linux kernel?
>>
>> If people want to provide implementations of such components outside of
>> systemd they would be more than welcome to do so.
>>
>> As systemd provides a lot of the functionality and shared API functions
>> that are convenient to use (i.e. the base building blocks) and as people
>> who are working on the systemd project are doing the actual work, and as
>> these are seen as core building blocks of a modern OS, then it makes
>> sense to do this under the systemd umbrella.
>>
>> There is no conspiracy here. It's just convenient. If other people want
>> to do this work, great.
> 
> Again, again and again:
> 
> I never assumed bad intentions.
> 
> Well… as it doesn´t seem to sink in:
> 
> I never assumed a conspiracy.
> 
> I never assumed bad intentions.
> 
> Do you need it again?
> 
> Ok, here is:
> 
> I never assumed a conspiracy.
> 
> I never assumed bad intentions.
> 
> 
> I see you received what I wrote as such and I am puzzled, cause I carefully 
> took care to make that perfectly clear in all what I wrote so far.
> 
> It seems I still didn´t bring this point accross.
> 
> This may be due to history and Lennart and others here, systemd upstream 
> having been called names and worse.
> 
> Yet *I* didn´t.

I have to say, this reply to my comment is quite strange to me. Your
reply seems to be completely focused on the part of my response which
said "There is no conspiracy here". I made some technical observations
about why things are structured the way they are and you're reply didn't
address or provide counter arguments or example.

I'm trying not to be directing anything at you specifically, but you've
neatly avoided all the technical points and moved the discussion in a
different direction that is more personal and emotive. I've gone out of
my way to provide you technical examples as to why the organisation of
the code is the way it is and yet nothing I can see in your reply so far
has attempted to discuss things on that level, and instead focused on
one small statement.

>>> 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 developer hs have stated this clearly several times over, but to
>> say it again, it's not that systemd *won't* accept patches for
>> portability, it's just that there will not be a codebase littered with
>> #ifdefs and optional codepaths that are not well tested by the core devs.
>>
>> systemd makes use of APIs that are currently *only* available on Linux.
>> If other kernels implement the same APIs, then systemd will work with
>> them just fine. If they implement equivilent functionality under
>> different APIs, then it's unlikely the systemd developers would support
>> this upstream directly as this would result in these #ifdefs and
>> untestable paths (by the core developers) that are very unattractive for
>> the upstream project.
>>
>> But you know what? This doesn't matter! Those developers who are
>> interested in those other kernels will just maintain their own fork of
>> systemd (and by form I mean a true fork - one which git facilitates well
>> where upstream changes can be merged periodically) where the linux calls
>> are split out into $whatever calls.
>>
>> This separate project can be tested by those developers and they can act
>> as the first port of call for bugs in their version but collaborate with
>> the original systemd for issues that are present in their upstream. In
>> many cases the developers of this fork would have upstream commit access
>> to. Such a world is perfectly feasible and it allows systemd to keep a
>> clean codebase and the downstream too. This is one of the cases where
>> committing everything upstream is not beneficial to either systemd or
>> the fork. Both are more individually readable and maintainable by their
>> relative maintainers. Everyone wins.
> 
> Ok, how would these forks address compatibility issues with upstream systemd? 
> 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.

So are you suggesting that progress be deliberately impeded to cater for
the lowest common denominator? I can't see that being popular!! :)

Such forks would obviosuly be by people who are interested and involved
in upstream projects. The fact that they do not have to keep up exactly
the same pace as upstream is *exactly* why they would be a fork in the
first place - if you consider the alternative would be supporting the
things they added in the fork upstream via a myriad of #ifdefs or
similar. As the core developers won't be testing this #ifdefery, they
either have to: 1) wait for a developer who does test such things to ACK
it, or 2) Do the release anyway, perhaps with broken support for $FOO.

However, if support for $FOO was in a fork, then the core developers
would be able to do their release unimpeded and the developer (or
developers) who care about $FOO can catch up when they get the time and
motivation to do so.

While it would be nice to do the release at around the same time, it's
certainly not mandatory. git makes these kind of things quite easy to
manage and I don't think such an arrangement is problematic.

If you, as a downstream, want support for $FOO, then you're accepting
that your decisions have consequences and repercussions. It might mean
you cannot update to certain other things until you've done the
underlying work, but that's fine. That's the choices you've made. This
is ultimately what happened with the systemd-shim stuff from what I can
tell and it's also what happens with some distro spins (e.g. Ubuntu
might be released before it's Kubuntu derivative).

Forcing the upstream to wait is not going to help.

As I mentioned, the people interested in $FOO would also hopefully be
upstream contributors too. Changes they make that make sense for
everyone will be implemented upstream and then merged into their
downstream. I don't see such developers working in complete isolation -
it's a symbiotic arrangement but ultimately upstream does not get held
to ransom or held back if some downstream becomes unsupported or it's
popularity fades.

The problem is that people have been so far very big on talk about
opposition, but very few have actually put their money where their mouth
is (metaphorically speaking) and come up with the code. git makes things
easy here, so what is stopping people?

> I just again and again also see the pattern of "This is not our business" 
> where it was systemd creating friction for others.

I really don't see this. If you don't want systemd, don't use it. It's
free software and you have a choice. It can only cause friction if you
want to use it. If you don't want to use it but some project you do want
to use does, then your complaints should be directed at that project,
not upstream. It's totally unfair to blame upstream for this!

If you see friction, then get involved, write patches or make
non-emotive, but specific and technical requests and accept the answers
given (perhaps with a little to-ing and fro-ing to ensure things are
properly understood, but ultimately there will always be cases where
upstream decisions are simply things that you, as a downstream consumer,
will disagree with - that's just life!)

I'm sorry to say, but large complaints about very vague and general
things like this thread are really not useful in such a perspective -
things have to be specific and clearly bounded. Each case then has to be
treated on it's own merits.

>> Again, you're totally confusing systemd as a project and systemd as a
>> PID 1. You need to accept and understand that distinction before anyone
>> here will take you even remotely seriously.
> 
> Okay, again my obversation:
> 
> 1) Embrace: Systemd implements functionality that is available elsewhere. As 
> PID 1 – service handling – and as project – DNS, DHCP, logging, handling core 
> dumps… and others.
> 
> 2) Extend: Systemd extends on this functionality. Which even makes sense. 
> systemctl status is wonderful. But it still does. Again I see this for PID 1 
> and for project.
> 
> 3) Extinguish: More and more on the first sight unrelated projects, apps and so 
> on depend on functionality that comes to distros as one entity: Systemd. More 
> and more it becomes difficult to run a fully fledged LInux desktop with an 
> alternative init system. More and more alternative init system developers need 
> to play catchup game by implementing stuff systemd implements, but which was 
> never fed into some standardization or stable API.
> 
> Again, again, and again: I see no bad intention. I see no conspiracy.

OK, so for the record I will say I agree with your first two points
here. I just totally disagree with your third.

I'll turn it around and ask you a question. If systemd is providing
things that others want to consume, is this really *systemd* making it
harder? Or is it just that the apps and projects in question that are
depending on these things see a very specific need that is being
fulfilled in only one place? Is this a failing of systemd or is it a
failing of other people who actively want to provide an alternative? I
would suggest the latter. The fact that other projects are not popping
up that solve these problems suggest that actually *developers* are
quite happy. If they were not happy, there would be more projects that
do these things. From what I can see, the complaints about this are
coming from people who are not actually prepared to do the work to
create said alternative - perhaps with the goal to spur some people on.
Good luck to them I say. Healthy "competition" is good!

Now personally, I'd *prefer* if developers actually work and hack on
systemd rather than something that implements the same thing. This is
open source so while 100 implementations of varying quality is totally
allowed, I'd rather see the effort involved in creating those 100
implementation actually focused on one, best of bread implementation.
systemd is a building block, a plumbing layer. It should be devoid of
the "preferences" and "each to their own" nature of things like Desktop
Environments which see various different approaches. But really that
doesn't matter, as that's just what I would like to see.

Ultimately, if this apathy of the developers to create competing
infrastructure is your definition of "extinguish", then I'll agree with
you. That's what's happening, but, importantly, this is NOT something
that's being done *by* systemd. It's happening because those that are
able to do such a thing are clearly unwilling to do it. Again, one has
to ask why?

> This is just what I *observe* and partly how I see similarities to Embrace, 
> Extend and Extinguish.
> 
> Heck, I am not even sure Microsoft had this strategy from the beginning.
> 
> I am pretty sure you didn´t have this strategy. I am pretty sure Lennart did 
> not have it. I am even pretty sure you or Lennart has it now.

Form the context I'm not sure if your last sentence in the above is as
you intended? I think it's saying the opposite of what I *think* you
were wanting to say, but please do clarify.

> But I see outcomes of the way how you currently handle things. Not *intended* 
> outcomes, but still outcomes.
> 
> And I stand by it by pointing this out.
> 
> If you can´t handle this… fine… don´t. But thats how I see it.

I accept your observation but I think you're attributing it wrongly and
unfairly. The way in which you're suggesting it appears to be designed
to impose a prejudiced, negative view point and I don't think it's
something that is beneficial to discuss in such a way here.

>> You are reading into it what you want based on your
>> preconceptions and then building up a case based on that. This is really
>> a case of apophenia, but people just don't see that because they are so
>> blinkered by their prejudices.
> 
> I am not fine with it. You don´t know what I do. You just interpret it.
> 
> As do I.

My statement above was indeed poorly written. This is my observation
based on your writing here and several similar posts I've read over the
last couple years. Sorry if this came across too personal.

> Its the only access I have to this world. I interpret what I see.
> 
> No what does make your interpretation more valid, than mine? What?

This is an interesting point actually.

I'm not directing this at your or my opinion  here but this is a related
and useful read:
http://www.iflscience.com/brain/no-youre-not-entitled-your-opinion

> 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.

I appreciate that's not your intention, but I hope you appreciate that
when you're the first person to say such things that's fine, you can
discuss things and get a response you disagree with and let the
discussion fade and die out. When the topic is discussed over and over
then there is a point when, regardless of the intentions of the
individual, by going over old ground *again*, it takes the patience of a
saint to not treat any such discussions some kind of continued attack
against the project.

> Yet, I interpret your reaction to me as if I attacked you.

I apologise if it came across that way. I concede some of the wording at
times was more directed than I had intended and should have been phrased
differently. It was more meant to be general observations of things I'd
seen before time and time again that also fitted the patterns of your
interactions, regardless of your no doubt good natured intent.

> 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.

I consider it (mildly) harmful too, but I think it's a natural thing at
the same time. People are afraid of change. I am thankful that the
distribution community I work with were generally very open minded. They
didn't see this as a fundamental departure and once they started using
the features provided they where pretty happy generally and just go on
with using their systems. I watch on the debates around the issue with a
not insignificant amount of disbelief about how passionate people can be
about something that in many, many cases, has very obviously not been
tested properly in a clean, solidly deployed and integrated environment.
I obviously can't tar everyone with the same brush and this is a massive
generalisation, but this is generally what I've observed.

> 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.
> 
> Its causing harm.
> 
> Very much so. Right now. As we speak. And I am concerned about it.
> 
> I am confident that Debian as a project will manage. But I see the cost it has 
> to the project. And I am very deeply concerned about it.

I think you should try to relax a bit (if you can find a way to do so).
I know it's a turbulent time, but it will fade and it will settle.

There will always be a section of the community that will disagree. I
don't think Ian Jackson will wake up one morning and say "ahh well, I
tried, I'll just install systemd now and do something else". Some things
will always stay fundamentally divergent and I think accepting that is
the way to being at peace with it! (I've seen very much the same
reaction to the polarising referendum choice here in Scotland - its a
fundamental facet of human nature!)

>> 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 again and again 
> and again triggers much of polarity and resistance, I´d ask myself whats going 
> on there. Which brings me back to the point why I started this thread here.

There is an expression too here that fits: You can't make an omelette
without breaking eggs!

I guess you're probably seeing all the people who are disagreeing
however. I see all the people collaborating - people from different
companies, communities; doing things in embedded, in massive server
deployments and management. I see all the things where people are
putting together awesome things. I see people enjoying a tasty omelette!

Believe me when I say I spend far too much time reading all the negative
and complaining things. I'm usually fairly good at not getting drawn
into lengthy email discussions, but I failed here :)

> Well, okay. I don´t follow this list for that long already. I read here and 
> there about systemd. Blog posts from Lennart but also critical feedback. Yet… 
> as Debian was not affected, it was kinda remote to me. So… I think its 
> understandable I don´t know five years of history.

Yes this is understandable, but you will appreciate that going over such
things again and again for upstream people is very, very frustrating and
this will likely be reflected in the tone of their replies (or implied
by the complete absence of them). Interpreting such things as
fundamental hostility or non-engagement is unfair. It's will often be a
product of the circumstance.

> And as these concerns are now this tells to me that those who have the 
> concerns either are not up to date that they have been address or otherwise 
> don´t have the impression that it they got addresses. In some time concerns 
> may have been addressed but information about it didn´t get throw. But in 
> other cases it may just mean you deemed the concerns as being "irrelevant".
> 
> And this, in my eyes, it not quite a respectful way to deal with concerns.

Perhaps it's not respectful if considered individually and in isolation.
But it's also not exactly respectful to come to upstream and ask the
same things over and over again. It could be argued that it also shows a
lack of respect not to properly research and reference previous
discussions. Ultimately respect is a two way street and it has to be earned.


>> Honestly, I've been following this project since it's very inception and
>> I from what I see your opinion of it has been formed around notions that
>> are pretty much entirely fictional or based on second hand
>> information/FUD. The accusations you make are often wildly technically
>> inaccurate and you seem to offer no credit to the devlopers with regards
>> to their collaboration.
> 
> This is your impression. I, as should be obvious right now, see this 
> differently.

Another case of agree to disagree I think :)

> Actually what you write above follows a similar pattern: Its the easiest way 
> to develop things. 

I also said a lot of other things too. The ease of development is one
factor. As I've outlined there are lots of others too. I've tried to
give a balance of reasons that all contribute, so summarising it as
"this is easiest" is a bit unfair.

> Okay, it may is. For you. But did you consider the cost it 
> creates for others?

Yes. This has been considered and the balance has been found and that
shapes the way things are done currently. It will continue to evolve
over time as it has up until now. There are costs all over the place in
doing things in certain ways (I've outlined some of them already) and
these are all factors.

>> I've been doing the rounds on mailing lists, distros and conferences for
>> years. systemd is one of the most open projects with regards to doing
>> the conference circuit and talking to people - all over the world and
>> with interested parties both commercial and community run. There is no
>> end of opportunity to speak with the systemd developers - often in
>> person - and discuss the issues. The regurgitation of the same old stuff
>> on mailing lists today no longer warrants further discussion for the
>> most part. Doing so just soaks up developer time (and it takes a *lot*
>> of time to reply to these things - this email alone has likely taken me
>> 20mins+ - I'd much rather developers give such "feedback" a brief read
>> over for any salient points and then ignore it and get on with designing
>> and writing code and making a difference.
> 
> It is your free choice to do with your time what you want to do. I am in no 
> way forcing you to respond to my mail.
> 
> It seems to me you felt some urge to respond, as I felt urge to respond to 
> you… thats okay. But thats something you feel or think, or I feel or think. So 
> I give all responsibility on how you spend your time back to you.
> 
> I am not responsible for it.
> 
> As you are not responsible for that I read your mail so late and then not 
> being able to sleep and just put it away till tomorrow.

Again, as with a previous reply chunk pointed out above, your reply to
this section has completely missed any technical and relevant point to
the fundamental matter at hand and focused on a personally discussion
point - that about finding time and desire to reply to mails in discussions.

I'm sorry to say, but you've again sidestepped the actual core
discussion in any qualitative way and not responded to my technical points.


>> 1. for the avoidance of doubt, I don't mean anything nasty by this - I
>> just mean replying just continues a pseudo "discussion" with someone who
>> is not in any way listening to your arguments or accepting your
>> technical opinion - it's just a never ending discussion that leads
>> nowhere - it has to be starved to die off and cannot be fed.
> 
> That I received as a personal accusation.
> 
> I work with Linux for more than 10 years. I do system admin work, I give Linux 
> trainings and and and…
> 
> Even if you try to do it politely. For me I received it as "You are a troll 
> anyway."

I apologise if you interpreted it that way. I think I clarified this
above already to the best of my ability, so won't go over it again here.
I will restate that I didn't intend this personally, but accept that you
interpreted it that way. So, I'm sorry for that.

> Now I agree to disagree.
> 
> From the thread so far I understand way better why people are concerned, why 
> systemd as a project of developers, as a umbrella projects of building blocks 
> as you call it and as PID 1 triggers the amount of polarity it does:
> 
> Or as Aaron Seigo carefully tried to put it:
> 
> Aaron Seigo, four paths, 7th of October 2014:
> http://aseigo.blogspot.com/2014/10/four-paths.html
> 
> How the way Lennart and other developers here treat people as I perceive here 
> and there also in how I feel being treated here has a contribution to the 
> reaction and outcome they get. That doesn´t excuse name calling or worse. But 
> it partly makes it understandable or explainable.

I think that's unfair. You're already joining in a loaded discussion.
I've already outlined above why you are, by the very nature of your
intervention, pre-loaded with the history of that topic, even if that's
not fair on you!

If the reply to your initial mail was simple "Sorry, but this has been
discussed before. If you want to discuss any specific points, please
grab me in the corridor at the next conference for 10 mins and we can
chat it over." would you have let the discussion die? I doubt it very
much. That would be a cordial reply, but it won't help you.  A lack of
further reply would likely have left you with a similar degree if
disappointment and disillusionment with the project. Of course this is
impossible to say for certain and I don't want to project any feelings
on to you for situations that didn't happen!


Also I know Aaron fairly well. We've met on several occasions and I
follow his posts and blogs and I consider him a friend. At the same
time, I disagree with his stance on things at times and have always
disagreed with his feelings regarding Lennart. I won't go into the
details, but I feel it's in many cases the responsibility of interested
parties to get involved and pull, rather than for upstreams to push. I
think the latter imbibes some concept of entitlement that is not how
things can (or do) really work. I'm someone who will get involved in the
things I think I need to know more about. I've always been happy with
that approach over a myriad of projects that have piqued my interest
over the years. I think accepting peoples opinions of people without
dealing with them with your own issues on your own terms, is inherently
prejudicial.

> And thanks for putting the effort in the response you put into it.

I know the effort it takes to write such replies. I hope you are able to
put as much effort into integrating systemd cleanly in Debian in a way
that most users would not even notice! (if they don't notice, you've won!)

I hope this further response to you has been more cordial than my first.
I haven't read over it, so I hope it flows OK and I've not accidentally
slipped into any kind of personally directed statement again like I did
occasionaly last time. If I have, please try to read it as if I hadn't
as it was likely just the default prose style when replying to an
individual regarding a pattern that generally occurs, and entirely
unintentional.

Anyway, I wish you all the best.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/