is systemd really all that bad?
 

hi guys,

i know most distros are switching to systemd
and i been reading a bit about systemd

i cam across a few tutorials/explanations regarding systemd and on the
one video there was a comment.

"It looks like someone is trying to "microsoft-ize" linux !! In the future i see it as "do what we say, not as you want to " mindset. and I don't like it. I use linux for a reason, i guess it's time to switch to BSD !!!!!"

what did the poster mean by this...is systemd really that bad...?

is it a bad thing that distros are going this way?
why does the poster feel the previous init system was so much better?

i value all your opinions

init.d, although it doesn't exactly read in a clearly obvious manner is straight-forward.

systemd isn't.

Want some reading?

You might also find this useful:

https://www.linux.com/learn/tutorial...-using-systemd

I don't like the all-encompassing binary blob aspect of systemd, but it does seem to be a done deal as far as most distros are concerned.

There's a Linux sysadmin in my LUG who says, that, when systemd works, it works great; when it doesn't work, diagnosing the problem is a real pain.

There is a reason a lot of distributions are going to systemd and getting an understanding why can be a real education in how a modern OS starts up and the issues involved.

The fundamental issue is that a lot of the services that need to be going after the system starts up depend upon each other in multiple ways and trying to decide which one to start first, which one can start and be put on hold, and which can start later can get 'real interesting'

There is a long history of system startup programs and I have seen an article on that history that was amazing in that there were so many of them just for Unix style systems. I don't know if that article is in the referenced additional reading links above, though, but it does appear that those links are to some good information.

As for the complaints, gripes, and bitchin' ... well, that's the community. Everybody has their favorite and a lot of folks don't like change and sometimes they get a bit hyperbolic and exaggerated in their rants. These rants may have some interesting points but separating the wheat from the chaff can be a bit of a challenge.

The distribution people are pushing their own particular flavor of a Linux solution. You choose which to use based on what does best for you. One of the nifty things about using Linux is that you can into the choices the 'experts' make and learn a lot about the technologies you use on a daily basis. That education is a real eye opener into just how much there is that many just take for granted.

And keep in mind that many of the decisions about the system design are much more than just technical issues. There are priorities to weigh against options, social factors to consider, intended market, and other factors that can be rather subtle. A lot to learn about there, too, if you have the interest.

These systemd threads always run for a long time.
Often after many posts, people just agree to disagree.

Personally, I don't like change if it is purely for the sake of change.
If it ain't broke you don't fix it!

I like the heck out of systemd

It really is that bad.
 

Systemd is the worst thing in the universe. Dennis and Ken didn't write it in the original Unix, so it must be a Windows construct. It uses binary data which will lock away your data and throw away the key, just like the rest of the binary data on your hard drive. If systemd has any value at all it's so that Red Hat can turn it's stable distribution into a Windows Server clone but worse because stability is overrated and they're not interested in making money anymore. The unit file ini format isn't an unstructured text file so that's just dumb. Byte streams are way faster than JSON, so the journal is useless. It's also not one of {s6, openrc, sysv, upstart}, so it's just reinventing the reinvented wheel again. If everyone would just pretend that our broken programs aren't broken we can stop pretending to fix them by fixing them.

Did I miss anything?

I wish there was a book about SystemD because after using it for now several years I still don't really have a real grasp about all the whistles and bells. And they just keep adding stuff to it.

Other than that I don't really care about the future of Gnu/SystemD

Not to quibble as I quibble, it's not GNU/SystemD. It's Red Hat System D.

Here's an interesting article in defense of SystemD. http://0pointer.de/blog/projects/the-biggest-myths.html

I have been looking at SystemD in a VM of Scientific Linux. I think it's important to separate complaints about how SystemD works from resistance to having to learn a new way of doing things.

I'm not saying this to take a position on SystemD. (If the day ever comes that Slackware goes SystemD, I'll probable go BSD.)

I am saying it because I realize that part of my resistance is that SystemD is a new foreign language that I really don't want to have to learn.:) I need to separate that part from the rational parts. As long as rsyslog is installed and working, maintaining the traditional /var/log structure, the greatest part of my objection to SystemD is alleviated.

I think people get emotional when talking about this and most of the times get lost in their arguments...

Systemd provides some very, very nice features... Good cgroups integration and logind is just the tip of the iceberg (and two of the best things it provides)..

The problem (and the reason why systemd is considered bad and evil) is that it provides all of this in a monolithic manner and then straight up lies about this... Systemd (as opposed to what their lead-developer say) is as monolithic as the Linux kernel and this does not affect the end-user as much as the eco-system of developers that decide to use it's features... To make matters worse, those features are usually of use to important projects (like Gnome or KDE) so if they decide to, for example, depend on logind, every system that wants to run KDE will have to boot with systemd (even if KDE wouldn't care who the init is and just care about logind and cgroups). To make matters worse, systemd has it's own dependencies (enough to basically define what the base part of an OS, the one that affects virtually every other app, should be)... This can quickly turn into a disaster... Ohh, and the best part is that if they decide to depend on some library which depends on some kernel functions which are not part of the official kernel (like, say kdbus).. Well, everyone that wants Gnome or whatever app (which just needs some functions provided by systemd, not caring about the actual login system) will have to use systemd which would want a patched kernel... Of course, for now that won't happen since kdbus will probably (eventually) be integrated in the kernel and is still not a hard-dependency, but just the sheer fact that this could happen in the future... You see the problem of creating a dependency chain?
To me, systemd is similar to sticking with "goto:"'s in the code..

In short, this is an attempt of vendor lock-in.

I personally live fine without systemd.

i wonder, have there been similar "wars" in the past?
about softwares that are now just accepted, even by those currently complaining about systemd?

Yes BSD init v SysV init

No, they wouldn't. They would be able to use any system that provides the same DBUS interfaces that systemd-logind provides, since they are not dependent on systemd-logind directly.
Now, this is basically the definition of FUD, Fear, Uncertainty and Doubt, without any actual information that this happens in the real world.