The question is, can this be blamed on systemd?

That's pretty funny Tobi. Real-world problems solved in KDE? That'll be the day.

KDE has been out 20 years and it's still bug-ridden, thanks in no small measure to the arrogant, perpetual over-reach of the KDE team themselves. What makes you think its problems are suddenly going to disappear once this new and invasive technology called systemd is injected into its bloodstream, given that systemd is even more more complex, and has even fewer developers behind it? One bug-ridden and over-engineered codebase gets married to another bug-ridden and over-engineered codebase, and you're trying to tell us it's a match made in Heaven? This marriage bed will see bugs multiply, not disappear. I can guarantee you in another 20 twenty years people will still be trying to solve problems in systemd and KDE, no thanks to the headless engineers responsible for the mess. Or perhaps they're not headless after all, but just following orders to make sure government and corporate malware is granted permanent access to the operating systems we will be using?

2 members found this post helpful.

You claim to have examined systemd, and since you are so against it I guess you have examined all those problems that are "inflated" and can show us why they not exist and how systemd does not solve them. Is your standpoint seriously "I don't have these problems, so they are not existent"?
Don't mind to answer that, I am not expecting an answer, since you also refuse to answer my previous questions.

You see this is where we have a problem. I already have a thousand and one things to do - maintain firewalls, VPNs, file and print servers, whatever. And I'm not a coder, so even if I did have the time to develop alternatives, I wouldn't be able to do it. Are you saying I - with my background in philosophy and theology - have no say or stake in Linux now? The only people according to you who have a say in how Linux develops from here on are the engineers?

If so, you're missing something quite important: technology is very much informed by philosophy. Poettering himself started out developing systemd because he thought he could do the init system "better", and one person's concept of what is "better" is a philosophical concept, not an engineering concept. Engineering is just the implementation. I certainly have a pretty poor grasp of engineering, but over the years I have found my engineering friends have just as dismal a grasp of philosophy, and believe it or not, philosophy drives technology just as much as engineering does.

1 members found this post helpful.

Linux distributions, like any other open source software, were always done by developers and engineers (you don't have to be an engineer to be a developer). It doesn't matter at all if they are influenced by this or that philosophy, software doesn't write itself, distributions don't develop themselves, so, yes, the only ones that have a say in how their projects develop are the ones that actually develop it, regardless if it is the Linux kernel, a distribution, or something like Open Office or KDE. You are not entitled to tell other people how they should do their work.

Certainly, if all the major distros and the upstream developers adopt it.

Sorry, but I can't follow that logic. Isn't it the fault of those people that abandon a project or are not stepping up to take it over when they need it in the first place that you have less options? systemd just provided one more option, are you blaming it for being the most used option?

Yes I am hot-headed, and I should not use crude language here. Sorry.

I just get angry with the choices being made these days by people; there seems to be a drive to dumb down the options and the discourse, not just in Linux but elsewhere in human activity. In case you're wondering, I should add that I inherited a very strong love of Germany from my grandfather, so please don't misinterpret these attacks of mine on your countrymen as closet anti-German sentiments. I sometimes get the feeling you are strongly defending the people involved just because that is your suspicion.

2 members found this post helpful.

Why would a KDE developer need to concern himself with the details of NTP at all?

But they're entitled to tell me how I should do mine?

1 members found this post helpful.

I don't care from which country Mr Poettering is (actually, he was born in Guatemala, so technically he isn't a German). You can be assured that there are certain parts of his personality which I don't like at all, but that does not have an impact on how I look at his work.

If they abandon a project they've successfully maintained for decades, and the difficulties that made them abandon it are caused by the upstream adoption of systemd - do you seriously blame the project maintainer? That's like blaming the victim of a crime, instead of the perpetrator.

1 members found this post helpful.

No, of course not.
But as a non-developer you have use what others develop for you. If you want to have a say in how software you use is developed you either have to become involved in the software project or pay someone to develop software how you would like it. No developer, not the systemd people, not the KDE developers, not the sysvinit maintainer, not the kernel developers, not the Gentoo, Debian, Slackware devlopers, ..., owes you anything but the source code (and not even that when the project does not have a copyleft license). They develop the software as they see fit and give it to you for free, they assemble their distros as they see fit and give them to you for free.
You are free to use them or not.

3 members found this post helpful.

Read the blog post linked earlier in this thread, please.

1 members found this post helpful.

When the other people have a paid day job to serve paying customers, the paying customers are entitled to tell them what work they should do.

When the other people have a paid day job to contribute to the wider community, the wider community is entitled to tell them what work they should do.

When the other people care about their users' requirements, the users will be listened to, and encouraged to tell them what work they should do.

When the other people have taken custodianship and exclusive commit rights to community developed code, the community has a continuing right to tell them what work they should do.

And of course, the community has an absolute right to freedom of expression.

And of course, developers have an absolute right to ignore feedback and suggestions. It's a right, but it's also stupidly self-harming. Developers who believe "You are not entitled to tell other people how they should do their work" will find themselves in the middle of an angry community, or facing hostile forks of their code.

And when forks happen, well-mannered developers will permit the fork to co-exist, and give advice, and encourage the exchange of good ideas, and bad-mannered developers... won't.

And bad manners from developers teaches bad manners to the community.

It is left as an exercise for the reader to find an example of a self-identified cabal of such developers.

5 members found this post helpful.