Yes, I'm not a mod, nor do I want to be (and I'm definitely not qualified to be), but we should carry out peer moderation. I think peer moderation should be carried out.

Thank you for understanding.

Gezley,

If you study those bug reports you will find out that 90% of the bugs are not related to problems of systemd.
The problems that are related like crypttab are being solved or are solved in later versions than 208 / 215 used by debian

...what!? How can you expect to be taken seriously when you start fabricating such blatant untruths about the GPL? The GPL is nothing more than a copyleft license that forces users of your code to release their code under similar terms. You can release intentionally confusing, undocumented code under the GPL as much as you want. Then other people can, if they want, start unravelling and documenting your code and release their changes under the GPL (ie. release a cleaned up fork). Even if there WAS some stipulation about documentation requirements in the GPL (which there isn't and shouldn't be), systemd has FAR, FAR exceeded any minimal requirement that could possibly be assigned.

When you write any library/module/etc. that is referenced in other code, you generally maintain an external, documented API, and an internal private one. This whole idea led to the development of code abstraction in object-oriented programming, in which there private variables/methods that can ONLY be used by the class itself and not by foreign code. The whole idea is to maintain a stable outward-facing API while being able to update/modify/rewrite/reimplement the actual library code itself without affecting programs that rely on that API. If writers of third-party utilities start using undocumented parts of the API that are not deemed to be stable, then if this code gets modified in the future, it either breaks the third-party utility (which was doing things it shouldn't be) or necessitates adopting a known unstable and unoptimized feature into the API to maintain compatibility with bad third-party code. There are tons of examples of bad actors relying on code they shouldn't, and if you wish to see the bad side of this, look no further than OpenSSL, which is a nightmare because it tried to maintain so many exceptions for every possible use of its code to avoid breaking anything (and led to a massive security vulnerability and global outrage).

The parts of systemd that are stable have decent documentation and the parts that aren't stable SHOULD NOT be used by third-party code unless they want to rewrite everything later (and there are other dangers when using complex code that you may not fully understand in a manner that was not intended...). So the API is pretty much documented just as it should be I think...

3 members found this post helpful.

So they were in fact related to problems of systemd, but have been fixed in later versions?

How about the guy on the Debian systemd bug tracker whose system would not boot once he upgraded to Debian with systemd? Something to do with him having LVM on Software RAID (which I also use on a server locally)? We should just ignore these problems because they're not serious, or they're not systemd problems, or who uses LVM on top of Software RAID anyway?

There's a guy on this thread (# 128078) who manages hundreds of systems. He got badly stung with systemd. Now he has set up his servers to ensure they are never upgraded to a release featuring systemd. That's just one solitary sysadmin. Multiply that by tens of thousands around the world and systemd looks as though it is in trouble. The problems with it have not reached critical mass yet. Rest assured they will.

did you post the wrong link or did you build in some of your fantasies in the description.
I read about a guy who failed in a fedora update in a VM, and now he will not update his home and office machines
is fedora nowadays stable software and not early adopter stuff exactly made to detect such problems?
btw, running fedora in an office ... ... a not very trustful person
do you have some better stories?

The author of post 128078 was a Fedora user was s/he? I wasn't aware Jessie was a Fedora pre-release.

And WHY do you THINK we keep saying that complexity is BAD?

Wake up and listen to the words coming out of your own mouth!!!

This is why simple projects with less complexity have fewer problems in the long run because it can be instances like these that cause problems in the first place. Yes, the systemd devs say not to use it, but who is stopping other developers from latching onto an unstable interface and using it? Who's also to say one of these unstable interfaces isn't going to affect other parts of the code by being unstable in nature?

How someone who has no practice of coding in C (according to his own words) can evaluate the complexity of a program written in C, or the level of complexity that is acceptable? Just curious

1 members found this post helpful.

And who can prevent someone to shot oneself in the foot?Can you provide practical examples, or is that a purely hypothetical lucubration?

Complexity in code, complexity in coding styles, and complexity in design are three different things. systemd is more complex in design than I would like but as far as I know they try to keep the codebase pretty clean (and refuse to add #ifdefs for compatibility). I don't know about the quality of the code either way (and seeing very clearly that you are not a competent enough programmer to judge yourself, neither do you), but when I said complex code I meant non-trivial code (which exists in nearly every project), not some abstract ideological complexity that exists solely in systemd.
Well it's good advice for at least one of us.
This situation is identical in literally every other library code, not just systemd. Smart downstream projects do not latch onto unstable interfaces and smart upstream projects do not freeze/expand their API just because downstream projects are too stupid to use it as it was designed. systemd is acting properly here (in regards to the API), whether you choose to believe it or not.
I'm sure you think you understand what you wrote but clearly you have little experience in programming and code design. There is a need to have some static API so people can use your code, but if you lock in every part of the API too early it makes it difficult to redesign later...they are merely remaining flexible for now. You can only design so much from the beginning before it starts to be too restrictive. All this means is that people will have to wait before utilizing functionality from these unstable parts (but they are free to use the existing stable APIs).

The user went from fedora 20 to fedora 21 according to the post.

this case has a few things to mention.

- fedora <-- testing (-current) for rhel
- upgrade instead of clean install (even we as Slackers recommend a clean install instead of upgrade) when going from 13.37 tot 14.0 for example
- fedora's packaging could be wrong

the above 3 issues are more likely to be the cause than systemd itself.
could be even a kernel cgroup prolem.

the journald issue he describes has been solved.

Can you or someone link to any reported reason from the systemd devs?

How about telling people what will happen when there is a single attack surface?

Why are interfaces that aren't supposed to be public, public?

2 members found this post helpful.

Sure. With a single attack surface, a security vulnerability can cause more widespread damage. And by single attack surface, you are implying systemd. I think that's a valid argument. I'll leave that for both sides to argue. (I'm pretty sure I said that I was more or less neutral on systemd?)

But that's a different issue from wishing malware on others, and that matter has been resolved peacefully.