Interesting and technical article above systemd + trolling

[jarlaxl]

The problem is that it was dark and the idiot could see neither the wiseman not the finger (if he had any)

[tomazzi]

I've found this article very interesting, professional and well backed by external resources.

I agree that the terms and language used are quite complex - so it's definitely not a "general-purpose" article.

In this aspect, the article is a failed attempt to show the problem - only a programmer or advanced, professional user (administrator?) can understand what is this all about...

Regards.

[edbarx]

I've found this article very interesting, professional and well backed by external resources.

I agree that the terms and language used are quite complex - so it's definitely not a "general-purpose" article.

In this aspect, the article is a failed attempt to show the problem - only a programmer or advanced, professional user (administrator?) can understand what is this all about...

Regards.

The heading for the article is:

Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise

Since it is a 'technical treatise', readers are expected to have the required technical concepts.

[tomazzi]

The heading for the article is:

Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise


Since it is a 'technical treatise', readers are expected to have the required technical concepts.

Exactly, but ... just take a look at some comments in this little thread ...

[jarlaxl]

The heading for the article is:

Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise


Since it is a 'technical treatise', readers are expected to have the required technical concepts.

Exactly, but ... just take a look at some comments in this little thread ...

+3.14
I d say take a look at all posts in this little thread and show me the moon.. oo sorry a technical treatised comment i meant.

[tomazzi]

+3.14159
...the moon is right up there...

[buntunub]

This is not a scientific approach. Was it peer reviewed?.. If not, sorry, no its not scientific ergo take it with the grain of salt it so richly deserves. Look, I am not a systemd fan at all, but if this is an attempt to unseat a now widely accepted part of GNU/Linux, then a much broader effort will be required. Why have there been no scientific studies done on systemd and its risks based on actual implemented use cases? The reason is because systemd haters just hate. They have no actual understanding of how things really work in the professional world. Another reason is because these types of things take a great deal of money to do, and they need to be done in the "right way", again of which they have zero understanding, so you see the dilemma.
As others have stated, the article is so poorly written that nobody will read it. It is the very example of how not to write -- anything. I suggest that anyone who is a software developer who wants to publish anything, first give your paper to someone that understands basic writing techniques. Otherwise, you are just wasting your time in even writing it because it will ~ never ~ be taken seriously by anyone.

[tomazzi]

This is not a scientific approach. Was it peer reviewed?.. If not, sorry, no its not scientific...

Your claim is simply illogical. Besides, this is just a blog - so naturally it represents author's private opinion...

A question which could be asked here, is whether this article is technically correct. IMO it is - but, if You can point out some inconsistencies, please don't hesitate to do this

... because systemd haters just hate

I would say that this is completely opposite problem: systemd fanboys are in majority those, who completely don't have a clue what systemd is and how it works...

Regards.

[Danielsan]

Well said! Thanks.

[edbarx]

'Hate'?!

Hate is too strong a word to describe the attitude of those who do not want GNU/Linux to converge to a limited set of software. If one searches Devuan's mailing list, one can encounter some who even declare they have systemd installed. For instance, I have it installed on one or a couple of Debian installations.

Being committed to conserve a wider application choice where GNU/Linux is involved, is no hate at all, but a commitment to conserve the wide choice GNU/Linux users were accustomed to.

As to systemd critics' referral to 'laziness', there are critics and there are others. In my case, thanks to systemd, I am now the author of a network manager for Devuan. This has been done thanks to others collaborating, criticising imperfections in my code and sometimes even acting like tutors. Needless to state, systemd trolls did all they could to bully me into a state of destabilisation and despair, but it was all wasted effort on their part.

[tomazzi]

In the past few days I've re-read this article several times, because I've felt that there's still something that I've mislooked. And finally I've got it.

Until now, I've thought that systemd tries to implement quite good ideas, only the code is crap - so all my work was foucused on fixing low-level bugs which systemd is littered with - but this article have opened my eyes - systemd is a crap.

However I'm not writting this post to just start another flame war. Please note this...

Two main problems with systemd are:
1. Every service which aims to be "compatible" with systemd must use the libsystemd library, because it needs to inform the service manager that it have started successfully and is operational. This of course results in incompatibility with other init systems.
2. Systemd is prone to failures resulting from services returning fault in case when they can't get a response from another service which they are dependant on. In such case either the "problematic" service is constantly restarted or ... killed, what in turn can lead to failures in other parts of the dependancy tree.

The above boils down to a single design problem: systemd does not offer checkpointing - the service is responsible for reporting a "ready" state to the service manager. This is a *very* bad design flaw - not only a new services have to be made dependant on systemd, but also *old* programs will suffer from the fact that they're not compatible with systemd.

...

I've carefully read the sources for DMTCP and CRIU, and I've also reviewed kernel's checkpointing code (which is described and linked to this page: https://ckpt.wiki.kernel.org/index.php/Main_Page )

The conclusion that I've came to is:

Most of that complicated dependancy tracking code in systemd can be trashed. The only thing which is really needed is to stop the service process once it starts to use the pre-activated socket (this can be done by the service manager, which owns the socket until it is passed to target service).
When the service is starting to write to a socket, it means that it's ready: configuration was read and initialization is done: Stop the service (SIGSTOP). Wait for other services to start. Continue the service process (SIGCONT). That's all.
The SIGCONT is sent to all services once all of them are started.
No checkpoints needed, no dependancy tracking, no unsolvable dependancy loops, total parallelism

What do You think?

Regards.

[spacex]

@ tomazzi

You wish..., but it won't happen. It's not supposed to be easy to get away with using other init-system. Because then most people would avoid systemd

Now that I've started building distros of my own, I'm actually pissed at Systemd myself. It gives me all kinds of issues with my unstable builds. Life was easier before systemd.

[dasein]

What do You think?

I think several things:

1) Thank you for wading through that obfuscated article to harvest this insight. Unlike the article, your post is quite readable, proving that one does not need to be opaque to be technical.

2) I can't help but wish that the "systemd debate" in this forum had stayed at this level, rather than degenerating into an intellectual sinkhole with endless neologisms, LOTS OF CAPS, and pointless font effects. (I know, I know... that would require reasonable moderation, so it won't ever happen here. But I can dream.)

3) Whether it's in the original article or in your analysis, this insight explains a great many systemd-related complaints/bugs under a single rubric. It illuminates a fundamental flaw that ought to disqualify systemd (and anything that depends on it) from service in mission-critical or life-critical systems.

(Frankly, even "fundamental flaw" seems too generous a characterization. I am reminded of the quip of Wolfgang Pauli who, in recommending rejection of a grotesquely flawed scientific paper, is said to have said, "That is not only not right, it is not even wrong!")

[spacex]

Actually, this one suites me better, as it is no pain to read it

http://suckless.org/sucks/systemd

[jarlaxl]

I will make here a hypothetical assumption (this exageration is just another safeguard against flamewars):

Start of assumptions-------------
-Lets say that we are a small and faithful (to what?) band of people,
-Lets say that the article is not badly written at all and is correct whatsoever
-Lets also assume that our faithful band is not affiliated with any institution/political/agendas.
-And despite that the technical committee/general resolution had thoroughly and technically examined the options of all other init systems and found systemd to be the best (among all others), and publicized its position here → a. thumb b. index c...
-we (but not the rest) know the absolute truth: “the systemd is flawed and the xxx is much better alternative with major implications on debian future and the wwiii”.

End of assumptions-------------

and the question that I could have already asked from the beginning is “what next?” (or “so what?”):
who (can/should) decide, or even set it as a discussion topic? e.g. TC, Dds (all?), any debian user (including grandmas)? And what technical criteria can be used to accept these changes? For which decision there should be a public statement to justify? What is in this case best for debian and where is it stated?

[edbarx]

-we (but not the rest) know the absolute truth: “the systemd is flawed and the xxx is much better alternative with major implications on debian future and the wwiii”.

Interesting... Shall we say, the kettle calling the pot black?

[Danielsan]

What do You think?

Regards.

I don't have the knowlodge to go so in depth, but I am glad you found the article eventually interesting. You should share your comments with the author of the article.

About systemd unfortunately we already knew is only the tip of the iceberg...

[jarlaxl]

Interesting... Shall we say, the kettle calling the pot black?

black kettle or pot i dont know, but its a matter to what it boils down

[Wheelerof4te]

http://www.phoronix.com/scan.php?page=n ... Non-Root-X

So, with this they:

1. Ended native support for older graphic cards. Now it's ''legacy'' style support.
2. Allowed systemd to do yet another thing which it's not meant to do. Why do I need systemd related junk logind in order to have quality support for my GUI?!
3. Exposed critical software to PID 1 init dependency monster.

But hey, at least now it's not root. Right? Right?!
It seems I won't be upgrading to Stretch with this hardware.

[Head_on_a_Stick]

^ I moved to rootless X ages ago.

It has the advantage of enabling the X server to be run as a user service to prevent reparenting to PID1