Why systemd is the way forward: technical arguments

Here you can discuss every aspect of Debian. Note: not for support requests!

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-11-29 19:58

CPU usage: wheezy takes ~ 5%. squeeze was ~ 3%. FreeBSD is about 3%. Statistics almost the same on all my computers, even ARM.
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby drokmed » 2014-12-15 01:38

confuseling wrote:This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd


I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.
Author of the Debian Linux Security Appliance Firewall howto, found here
Thread discussing it is here
User avatar
drokmed
 
Posts: 1167
Joined: 2007-10-03 19:24
Location: Saint Petersburg, FL

Re: Why systemd is the way forward: technical arguments

Postby golinux » 2014-12-15 02:30

+1, drokmed. You have seen the light!
May the FORK be with you!
User avatar
golinux
 
Posts: 1540
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-12-15 08:09

LOL ... I've seen the light and it was pitch dark :-)
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby tomazzi » 2014-12-15 12:47

drokmed wrote:
confuseling wrote:This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd


I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.


This wiki has been written as if systemd was a stable software, while if fact it's not.
And definitely it was even less stable at the time when the text was written.

As a result, and unfortunately, the wiki contains mostly misleading informations, half-truths, if not just lies.
For example:
Sysvinit/insserv has very little C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain.

The above suggests, that on the contrary, systemd has a lot of C code (what happened to be true) and is easy to debug (to find where the problem is...)
I can't imagine what kind of an idiot have written this. For sure, he heve never even readed the systemd code, not to mention trying to debug it.
And systemd has tons of bugs, which are not a result of the current alpha development stage - those bugs are effect of bad design, bad coding practices and ignorance.

Even the first listed feature of systemd is simply a lie:
Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.

It is obvious, that services which are dealing with databases or filesystems in general cannot be "shut down properly, regardless of its state"
But, this is only tip of the iceberg, problem with this kind of aproach is far more deeply rooted:
Those idiots are running sync() calls in several threads, to make in parallel - but unfortunately storage devices are "serial", calling sync() in parallel is simply stupid and pointless.
Things are even worse: those idiots are running sync() in detached threads - what means, that they are not waiting untill sync() is finished and are turning the power off. It is very likely that systemd can corrupt file system in this way.
This may not be visible on desktops, where usually filesystem is in sync long before the user will shut down the system, but on servers this stupidity may have serious concequences.

Regards.
Odi profanum vulgus
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: Why systemd is the way forward: technical arguments

Postby edbarx » 2014-12-15 13:27

Another brilliant post by tomazzi. Thanks for taking the time to explain technically what are the issues regarding the adoption of systemd at this inopportune stage.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: Why systemd is the way forward: technical arguments

Postby Head_on_a_Stick » 2014-12-15 13:50

@tomazzi -- are you feeding back all of this information to the systemd development team? (Without the ad-homenim attacks, obviously)

It sounds like they could use your help...
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12747
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-12-15 14:31

The systemd devteam actually knows all this.
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby Head_on_a_Stick » 2014-12-15 15:04

^ Ah, it was the proligate use of the term "idiots" that led me astray on that one...

Please stop the personal attacks guys -- if there is a solid technical point to be made, surely you can see that attatching ad-hominem attacks to it dimishes your argument?
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12747
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Why systemd is the way forward: technical arguments

Postby drokmed » 2014-12-15 17:12

Can I call myself an idiot if I don't become alarmed?

Again, excuse my ignorance, I've been away, but if systemd really is this out of control monstrocity that also appears to have serious design and implementation flaws, then why are nearly ALL of the linux distro's already embracing it? The old init scripts have their problems, sure, but they still work, maybe not at light speed, but they work.

Please endulge me, I have two thoughts on where this will go:

1. With all of this exposure, whether systemd stays in linux or not, will be forced to clean up it's act, fix all bugs, pull back on the "exceeding purpose", etc, which is a good thing. If they do all of these things, then it could become a good thing. Big IF's though.

2. Fortunately for us, many linux system administrators also have UNIX experience. After all, it's been around a LOT longer than linux. I won't go into a history lesson "do you remember when...", but I'm sure this controversy, justifiable or not, will cause a LOT of servers to move over to the BSD line. I left BSD years ago, because linux had much broader support in packages and hardware. That's not the case today. BSD has caught up, not entirely to be sure, but enough to move mission critical servers. That's a no brainer.

If systemd ever does become cleaned up, and even acceptable, it will be too late for servers. Friends of mine moved their servers to BSD years ago. I resisted, but now, it's the smart thing to do.

One other thing... the BSD folks also want to replace the aging init system with something better, but with what? I don't know the answer to this one yet, i'm still coming up to speed. I have a feeling they will do it right. Slow, but right.

Sorry to resurrect an aging thread, and thanks for the active responses.

It breaks my heart to see this happening to linux. It's like catching your wife cheating with someone you despise. Do you accept it, work with her, kick his tail, or do you sleep with his wife, dump them both, then move on down the road. Both options suck.
Author of the Debian Linux Security Appliance Firewall howto, found here
Thread discussing it is here
User avatar
drokmed
 
Posts: 1167
Joined: 2007-10-03 19:24
Location: Saint Petersburg, FL

Re: Why systemd is the way forward: technical arguments

Postby tomazzi » 2014-12-15 18:39

More on the sync() problem in systemd: (v218)
What I said before, is a tip of the iceberg which is only tip of another monstrous iceberg :) :
The asynchronous sync I've mentioned before is rarely used in systemd core, and this is much worse:
core/unit.c.3430: int unit_kill_context(): to big to put it here, so this is only the interesting part:
core/unit.c.3502:
Code: Select all
                if (r < 0) {
                        if (r != -EAGAIN && r != -ESRCH && r != -ENOENT)
                                log_unit_warning_errno(u->id, r, "Failed to kill control group: %m");
                } else if (r > 0) {

                        /* FIXME: For now, we will not wait for the
                         * cgroup members to die, simply because
                         * cgroup notification is unreliable. It
                         * doesn't work at all in containers, and
                         * outside of containers it can be confused
                         * easily by leaving directories in the
                         * cgroup. */

                        /* wait_for_exit = true; */

                        if (c->send_sighup && k != KILL_KILL) {
                                set_free(pid_set);

                                pid_set = unit_pid_set(main_pid, control_pid);
                                if (!pid_set)
                                        return -ENOMEM;

                                cg_kill_recursive(SYSTEMD_CGROUP_CONTROLLER, u->cgroup_path, SIGHUP, false, true, false, pid_set);
                        }
                }


Again: this the latest version of systemd: and practically every single service can be killed by power-off without any syncing (!)
/* FIXME: For now, we will not wait for the
* cgroup members to die (...)


How this is different from Winblow's "WaitToKillServiceTimeout"?
And obviously it's cgroups' fault, not systemd's

Back to asynchronous sync() (as they are calling it):
Making asynchronous (running in parallel) sync() is an evidence, that the devs have completely no idea what is sync for.
They are complaining:
/* It kinda sucks that we have to resort to threads to
* implement an asynchronous sync(), but well, such is
* life.

Well, this is stupidity in a flawless form.
The call to sync() is used to make sure that modifications made to a file up to *now* has been safely transfered to HDD - the program *must* wait before the file gets synced.
So for example, we can know, that the file in consistent state, before we start to append/modify other data or related files (especially important when dealing with database records and indexes).
So making a call to sync() asynchronous is plainly stupid, because this is exactly the oposite to what sync() is supposed to do... (!)

As this is used f.e. by journald, then it's quite probable that for this reason it randomly fails to save correct data.
But, who cares - "Just ignore it!"

drokmed wrote:Can I call myself an idiot if I don't become alarmed?

No, systemd was forced by former RedHad employees, who are now holding key positions in Debian structures.
They have decided for the users and for halve of Debian developers - that's all.

Regards.
Last edited by tomazzi on 2014-12-15 20:08, edited 1 time in total.
Odi profanum vulgus
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: Why systemd is the way forward: technical arguments

Postby twoflowers » 2014-12-15 18:50

That's te reason why "agile programming" discurages commenting code :mrgreen:

Nice work!
twoflowers
 

Re: Why systemd is the way forward: technical arguments

Postby Head_on_a_Stick » 2014-12-15 19:14

@tomazzi -- thank you for posting that without the personal attacks.

I don't understand any of it, but it sounds a lot more credible that way ;)
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12747
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Why systemd is the way forward: technical arguments

Postby dasein » 2014-12-16 00:42

Head_on_a_Stick wrote:...attatching ad-hominem attacks to it dimishes your argument?

Same thing true for typos? :mrgreen:

(Sorry, couldn't resist when I saw it)
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: Why systemd is the way forward: technical arguments

Postby buntunub » 2014-12-16 02:51

drokmed wrote:It's like catching your wife cheating with someone you despise. Do you accept it, work with her, kick his tail, or do you sleep with his wife, dump them both, then move on down the road. Both options suck.


That entirely depends on what his wife looks like.
User avatar
buntunub
 
Posts: 591
Joined: 2011-02-11 05:23

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests

fashionable