XLennart: A Game For Systemd Haters With Nothing Better To Do

[blackiwid]

Then go and try it yourself and read my post carefully. After that you are qualified to answer to this post. All you die is saying: "no not true". Mord than that i want to setup a chroot. No Discussion here. Or do you want to tell me forget the chroot and do it the systemd way? (Assuming your comment is correct)

You made here fun of yourself sorry you are a hardcore troll. you got proofed wrong on 3 from 4 points, if its lies or more likely you proofed that u dont know about the stuff you are talking about. but the guy that could not say much about point 4 and did admit taht he does not know about it enough is the guy that should proof to you that he is qualified, even you just proofed that you are very less qualified?

But thats typical for most (not all) systemd haters, they just have vague feelings never used systemd or informed deeply about it but just hate it because its different or new and they dont want to change habbits at all costs, and everything that dont work because of that is then systemds fault.

[Kemosabe]

You made here fun of yourself sorry you are a hardcore troll. you got proofed wrong on 3 from 4 points, if its lies or more likely you proofed that u dont know about the stuff you are talking about. but the guy that could not say much about point 4 and did admit taht he does not know about it enough is the guy that should proof to you that he is qualified, even you just proofed that you are very less qualified?

But thats typical for most (not all) systemd haters, they just have vague feelings never used systemd or informed deeply about it but just hate it because its different or new and they dont want to change habbits at all costs, and everything that dont work because of that is then systemds fault.

Prpbably this is very shocking for you but your first sentence is approx. the standard reaction in here. This is no argument nor does it proof anything. Nobody including you die even try to justify design flaws i mentioned. . .

[Guest]

I strongly disagree with posts above saying that systemd haters have never tried it.

It might be true for trolls here, but true systemd haters are generally sysadmins who were forced to use it and all their legacy scripts that worked well for 20 years suddenly don't work at all.
Some of these can be worked around (writing custom .service files) some scripts must rewritten from scratch (cgroup management).
Admins also positively have to workaround 'defaults' that are suited for desktops, but not servers etc (whoever tried using journald on CoW filesystem that is several TB big knows what I'm talking about).

Even if you are power user who used to have nice acpid config that handled all fancy actions like laptop lid open/close, you will get burnt by logind that will by default suspend.
Yeah, in last versions they added variable that autodetects external monitor plugged in, but for a _long_time_ this half-baked thingy was default.

List doesn't start or end there, but to conclude systemd does things differently and is nowhere near mature enough for serious application.
And unless they stop adding features, standardize configs & interfaces it won't be for quite some time.

[Nobu]

Set some nfs entries to /etc/fstab. Systemd will get stuck for over 2 minutes during shutdown and boot because it is too stupid to mount this. Let's ignore the fact my mounts are *not* systemd's concern, it even wants me to use NetwokManager to be able to mount it.

Add noauto if you don't want it to mount at boot...I thought that was common knowledge by now.

Of couse the systemd-networkd is being ignored and stupid NetworkManager-wait-for-online.service or something like this is required ...

Wait...do you want to use systemd-networkd, or not? I'm confused...

1) systemd should not even know about networkmanager. It isnt even installed on my system(s)!
2) systemd should not Mount anything
3) systemd shouldn't care about my network connections

1) "systemctl disable NetworkManager"
2) noauto, or switch init systems
3) "systemctl disable systemd-networkd"

[blackiwid]

I strongly disagree with posts above saying that systemd haters have never tried it.

It might be true for trolls here, but true systemd haters are generally sysadmins who were forced to use it and all their legacy scripts that worked well for 20 years suddenly don't work at all.
Some of these can be worked around (writing custom .service files) some scripts must rewritten from scratch (cgroup management).
Admins also positively have to workaround 'defaults' that are suited for desktops, but not servers etc (whoever tried using journald on CoW filesystem that is several TB big knows what I'm talking about).

Even if you are power user who used to have nice acpid config that handled all fancy actions like laptop lid open/close, you will get burnt by logind that will by default suspend.
Yeah, in last versions they added variable that autodetects external monitor plugged in, but for a _long_time_ this half-baked thingy was default.

List doesn't start or end there, but to conclude systemd does things differently and is nowhere near mature enough for serious application.
And unless they stop adding features, standardize configs & interfaces it won't be for quite some time.

I thought on this matter, why there is so much hate, systemd does much stuff automaticly that before sys admins had to do manual, so there will be maybe some people loose their job because less admins are needed. That I think is a reason also many of this sysadmins have, but who would argue like that. you cant argue like that, keep it manual so we keep our jooooffbbss....

Maybe I am wrong here who knows... to the stabalising stuff/protocols... if debian thinks they can bring it to a state they want to deliver they will get it done... if thats to less we really need a new debian fork WITH systemd just back to release only all 5 years a version. Why should the main developer not add features because of a small group that makes it not enterprise/old enough?

[mpppp]

Go fuck yourself. I bet you did not whine this way when there was no easy way to use something other than Sys V Init.

- heard about booting to sh as init to reset passwords
- heard about daemontools
- heard about runit
- heard about all the embedded stuff with custom init method
- heard about slackware sysv COMPATIBLE init method

You sure you did all the above and nothing of it was easy?

Besides, systemd is not an init system, it is a middleware based distribution. All the fuss other distro users do is justified but is misdirected at the merits or demerits of systemd.

I'd compare it to android userland instead. It doesn't matter how awesome it is, you either embrace it and depend on what google thinks it's best, or fork it and forever lag behind it in features.

Linux users have the option of sticking with stuff from the pre systemd landscape, plenty of it around, while mobile users have no such luxury. All those who choose to ditch systemd won't hurt anybody, so let it be.

[MoonMoon]

Ah nice, a systemd-"hater"-bashing article.
Just as an example: Set some nfs entries to /etc/fstab. Systemd will get stuck for over 2 minutes during shutdown and boot because it is too stupid to mount this. Let's ignore the fact my mounts are *not* systemd's concern, it even wants me to use NetwokManager to be able to mount it.
Of couse the systemd-networkd is being ignored and stupid NetworkManager-wait-for-online.service or something like this is required ...
Everybody may expect more and more services/applications will depend on systemd in foreseeable future. It will be mandatory in case you want to use a modern distro at some point.
It's a painful mess. But hey - it is so cool and fancy to bash all critics these days - how fucking cool and trendy are you?

Funny, I have NFS mounts in my fstab and use systemd-networkd for setting up my network, but have none of the problems you mention. Maybe its your configuration that sucks?

[MoonMoon]

Are these DESIGN bugs reported, too?
1) systemd should not even know about networkmanager. It isnt even installed on my system(s)!

You may be right with that.

2) systemd should not Mount anything

Of course it should. It is part of the dependency managing, otherwise you wouldn't be able to define that your database server has to run after its database was mounted, for example.

3) systemd shouldn't care about my network connections

Of course it should, same reason as for #2.

4) this is probably the most rediculous one:
Did you install a Webserver in a minimal chroot using php-fpm? Php -fpm really depends on systemd! You may choose:
* expose syszemd Sockets to your chroot
* disable Systeme notification in php-fpm

So other services using a systemd interface is somehow now also the fault of systemd developers, not the developers of the service? Now, that is ridiculous.

[NotMine999]

Cute...but not worth the jihad in these threads

Phoronix: XLennart: A Game For Systemd Haters With Nothing Better To Do

It seems that a good number of Linux users who despise systemd as an init manager have a lot of time on their hands... From making websites bashing systemd, forking distributions over their position of using systemd, personal attacks against systemd developers, to writing page after page of forum comments about negative points of systemd. There's now even an anti-systemd game...

http://www.phoronix.com/vr.php?view=MTg2Mjk

Another entertaining "systemd" forum thread....

Here's a design suggestion for "systemd" developers, and they can use it "for free"...under GPLv2 terms (they can use it but I still get credit for the idea).

How about a CLI and GUI interfaces that would allow the user to select which aspects of "systemd" they wish/need to use? It can be called "controlpaneld". Each internal aspect of "systemd" would have it's own panel that opens to a "choices & dependencies" screen where "enabled" and "disabled" choices and a module "description" would exist. You want "systemd" but don't want/need "firewalld" or whatever, then turn off that module. In the background a different binary called "dependencyd" can sort out what is needed to make the user's choices work and even provide a summary and panel with "accept changes/revert changes" choices.

By default, "systemd" would have a core binary to hook all the modules, but cannot be disabled without replacing the entire "systemd" implementation with something else that handles "init" functions. That idea mirrors what you can do today in very few distributions (LFS?, Gentoo). The remaining elements of "systemd" could then be "optional" and chosen based on the needs of the user. A desktop or gamer might always choose "enable all" whereas others might want fewer "systemd" modules.

Why suggest this? Instead of taking an "use it all or don't bother with it approach" (my own perception of the "systemd" project, and somewhat mirrored by "systemd" supporters in this thread), "systemd" can try to meet a wider potential user community "half way". It would also help support "systemd" arguments I seem to remember reading elsewhere that "systemd" really is "modular", not to mention be a PR "plus" showing that you can run "systemd as init" without having to load/use a bunch of stuff you don't want/need.

Time for the "systemd" supporters to come out and bash me and call me a "hater", right? Isn't that the way this forum thread works?

[MoonMoon]

Another entertaining "systemd" forum thread....

Here's a design suggestion for "systemd" developers, and they can use it "for free"...under GPLv2 terms (they can use it but I still get credit for the idea).

How about a CLI and GUI interfaces that would allow the user to select which aspects of "systemd" they wish/need to use? It can be called "controlpaneld". Each internal aspect of "systemd" would have it's own panel that opens to a "choices & dependencies" screen where "enabled" and "disabled" choices and a module "description" would exist. You want "systemd" but don't want/need "firewalld" or whatever, then turn off that module. In the background a different binary called "dependencyd" can sort out what is needed to make the user's choices work and even provide a summary and panel with "accept changes/revert changes" choices.

By default, "systemd" would have a core binary to hook all the modules, but cannot be disabled without replacing the entire "systemd" implementation with something else that handles "init" functions. That idea mirrors what you can do today in very few distributions (LFS?, Gentoo). The remaining elements of "systemd" could then be "optional" and chosen based on the needs of the user. A desktop or gamer might always choose "enable all" whereas others might want fewer "systemd" modules.

Why suggest this? Instead of taking an "use it all or don't bother with it approach" (my own perception of the "systemd" project, and somewhat mirrored by "systemd" supporters in this thread), "systemd" can try to meet a wider potential user community "half way". It would also help support "systemd" arguments I seem to remember reading elsewhere that "systemd" really is "modular", not to mention be a PR "plus" showing that you can run "systemd as init" without having to load/use a bunch of stuff you don't want/need.

Time for the "systemd" supporters to come out and bash me and call me a "hater", right? Isn't that the way this forum thread works?

That interface exists already, it is called systemctl.
By the way, not everything ending in a d is a systemd part, firewalld for example.